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

[Robert Raszuk <[e-mail]>]

Well that's exactly the doubt I had ... I never thought we reached
consensus in the past (even rough) that BGP is to carry *ALL* LSDB state.
It was always cheery picking to what is useful for TE/SR etc ...

You now are describing the usefulness of this information as IGP monitor or
validator. Using BGP for filling that oracle seems quite shocking to me.
But maybe I am alone on this.

Thx,
R.

On Wed, Jun 8, 2022 at 2:14 PM Tony Przygienda <[e-mail]> wrote:

> I'm leaning the way of consistency. The subtle ways BGP-LS is _not_ IGP
> database really is already bad enough, now if it's only partial it's even
> worse.
>
> this stuff in LS is useful if you want to understand that's something is a
> flood reflector cluster and e.g. correlate the level 1 information you pull
> via another BGP-LS stream from inside the cluster. on controller as you say
> (or something along those lines)
>
> -- tony
>
>
>
> On Wed, Jun 8, 2022 at 1:42 PM Robert Raszuk <[e-mail]> wrote:
>
>> Hey Tony,
>>
>> Reading your note I am not sure which way you are leaning, but one think
>> for sure you agree that we should not be building and parsing the same TLVs
>> by two different protocols. That is already a progress. I have some
>> suggestions but will share it offline first.
>>
>> But now let's step back from general discussion and just focus on this
>> very draft.
>>
>> Tell me - why IGP reflection TLVs is even useful to be send by BGP-LS to
>> controllers ? What practical computation will controller do with this
>> information ?
>>
>> I hope we have not reached the point that whatever is invented in LSR WG
>> MUST be understood and carried by BGP - or are we there at this point now ?
>>
>> Thx,
>> R.
>>
>>
>>
>>
>>
>> On Wed, Jun 8, 2022 at 1:09 PM Tony Przygienda <[e-mail]>
>> wrote:
>>
>>> oh well, BGP-LS sanity train left the station while ago. Experienced IGP
>>> voices @ time of the spec creation tried to explain that re-encoding IGP
>>> sounds like a good idea on surface only and will cause belly aches down the
>>> road (which I'm dealing with regularly now in deployments, it's not
>>> pretty). BGP should have been used as a conduit carrying opaque IGP data
>>> (if one _really_ wants to use BGP). Now we went down the slippery road of
>>> cross-coding we basically have to re-encode every piece of IGP and the
>>> discussion whether "we do that in BGP-LS" is in my eyes largely academic.
>>> BGP-LS is already a semi-crutch IME, making it a partial crutch makes it
>>> probably worse ...
>>>
>>> my 2c
>>>
>>> -- tony
>>>
>>> On Wed, Jun 8, 2022 at 9:58 AM Robert Raszuk <[e-mail]> wrote:
>>>
>>>> Hi Les,
>>>>
>>>> For IDR to say “we won’t allow the BGP-LS extensions draft for this
>>>>> (already approved) IGP extension to become a WG item” indicates that the
>>>>> IDR charter now allows it to make IGP extensions non-deployable (due to
>>>>> lack of BGP-LS support).
>>>>>
>>>>
>>>> If lack of BGP support for a protocol extension makes such extension
>>>> non-deployable it is no longer IGP extension. It is at best cross WG
>>>> extension.
>>>>
>>>> I get that BGP-LS truck got build and is running here and there - and
>>>> it is just for pure convenience of use used as transport for non BGP stuff.
>>>> But when it was build I have never seen declaration that it can take any
>>>> load produced by IGP for years to come.
>>>>
>>>> I don’t believe this is within the charter of IDR.
>>>>>
>>>>
>>>> You are saying that BGP should blindly rubber stump whatever other WGs
>>>> produce and take it on irrespective on data dynamics, amount, use case,
>>>> practicality of being useful in lots of production networks ? Sorry but I
>>>> do not think this is how IDR operates.
>>>>
>>>>
>>>>>  IDR certainly has the responsibility/right to review proposed BGP-LS
>>>>> extensions for correctness.
>>>>>
>>>>
>>>> If such review can only do cosmetic changes because it was already
>>>> approved by LSR WG what is the point ? If there is value in such review is
>>>> only to allow or disallow to add it to BGP.
>>>>
>>>> And this discussion is not about draft in the subject line. It is much
>>>> broader and general.
>>>>
>>>> Please keep in mind that last time I checked IDR stands for
>>>> Inter-Domain Routing - not Intra-Domain RDS.
>>>>
>>>>
>>>>>  As to whether the IGP extensions will ever get deployed, I consider
>>>>> that a moot question at this point.
>>>>>
>>>>
>>>> Sorry nope. We seems to have complete different views here. And yes
>>>> part of my voice is driven by completely different ways IDR vs LSR WGs
>>>> operation model.
>>>>
>>>> LSR approves ideas which are useful. IDR however approves ideas which
>>>> are not only useful, but have support from customers and there are at least
>>>> two interoperable implementations which exists.
>>>>
>>>>
>>>>>  Maybe the lesson to be learned here is that it is better to avoid
>>>>> this discussion entirely by incorporating the BGP-LS extensions directly in
>>>>> the LSR draft whenever feasible.
>>>>>
>>>>
>>>> Les - dynamics of BGP and ISIS/OSPF is completely different. Moreover I
>>>> would perhaps do not care that much if what IGP gives to BGP would be
>>>> opaque and carried as binary blob. Maybe even compressed.
>>>>
>>>> But some people insist this must be all parsed by each BGP node, each
>>>> value verified and parsed by BGP code then included in new BGP TLVs. That
>>>> is never ending stream of work which BGP protocol has no interest in.
>>>> Moreover real BGP features are pushed away because of this. That is BAD.
>>>>
>>>> Cheers,
>>>> R.
>>>>
>>>>
>>>>> *From:* Susan Hares <[e-mail]>
>>>>> *Sent:* Tuesday, June 7, 2022 5:58 PM
>>>>> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Aijun Wang <
>>>>> [e-mail]>
>>>>> *Cc:* [e-mail]
>>>>> *Subject:* RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
>>>>> call (6/6 to 6/20)
>>>>>
>>>>>
>>>>>
>>>>> Les:
>>>>>
>>>>>
>>>>>
>>>>> I’m glad to take this offline if you wish.   I’m sorry I misunderstood
>>>>> your question.
>>>>>
>>>>>
>>>>>
>>>>> Let me be specific about the two drafts
>>>>> (draft-ietf-lsr-isis-flood-reflection-07.txt and
>>>>> draft-head-idr-bgp-ls-isis-fr-01.txt).
>>>>>
>>>>>
>>>>>
>>>>> LSR is the key working group reviewing the TLVS in the OSPF/ISIS
>>>>> protocols.  The IDR WG is responsible for BGP basic functions (BGP-LS,
>>>>> SR-BGP, etc.).  If LSR WG agrees to additions to OSPF/ISIS, IDR does not
>>>>> cross review these features.  IDR only cross reviews any LSR draft that
>>>>> includes of the TLVS in BGP-LS for BGP.
>>>>>
>>>>>
>>>>>
>>>>> Is this a clear response?
>>>>>
>>>>>
>>>>>
>>>>> Since the draft-ietf-lsr-isis-flood-reflection-07.txt has past LSR WG
>>>>> LC AND does not have any BGP-LS TLVS – IDR has no reason to comment on this
>>>>> draft.   If IDR WG members wish to comment on the draft, then the
>>>>> appropriate place is the LSR WG, Routing AD (John Scudder) or IETF LC.
>>>>>
>>>>>
>>>>>
>>>>> I doubt the IDR WG will say “no more BGP-LS” as I have a pile of IDR
>>>>> drafts that specify more BGP-LS.  However, like Tony Li raises concerns
>>>>> about what goes in ISIS or OSPF, it is reasonable for people to ask “why”
>>>>> about additions to IDR.
>>>>>
>>>>>
>>>>>
>>>>> I hope this is clear answer.  You are welcome to tell me I missed the
>>>>> mark again..
>>>>>
>>>>>
>>>>>
>>>>> Cheers, Sue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Les Ginsberg (ginsberg) <[e-mail]>
>>>>> *Sent:* Tuesday, June 7, 2022 8:01 PM
>>>>> *To:* Susan Hares <[e-mail]>; Aijun Wang <
>>>>> [e-mail]>
>>>>> *Cc:* [e-mail]
>>>>> *Subject:* RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
>>>>> call (6/6 to 6/20)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sue –
>>>>>
>>>>>
>>>>>
>>>>> (I am already starting to be sorry I waded into this thread…)
>>>>>
>>>>>
>>>>>
>>>>> Sorry, but I find your response off topic.
>>>>>
>>>>>
>>>>>
>>>>> It is quite legitimate for the IDR WG to consider alternatives to
>>>>> BGP-LS – and even consider deprecation of BGP-LS.
>>>>>
>>>>> (By saying that I am not expressing support or opposition to the idea.)
>>>>>
>>>>>
>>>>>
>>>>> But it is NOT legitimate for that topic to be used as a blocker for a
>>>>> particular BGP-LS draft.
>>>>>
>>>>> BGP-LS is what we have – and it is widely deployed. If/when the IDR WG
>>>>> decides “no more BGP-LS” then clearly such drafts should no longer be
>>>>> written. But that state does not currently exist.
>>>>>
>>>>>
>>>>>
>>>>> In the real world we live in, as I see it:
>>>>>
>>>>>
>>>>>
>>>>> LSR WG decides what IGP protocol extensions will be approved.
>>>>>
>>>>> Once those extensions are approved it is NOT the place of the IDR WG
>>>>> to say “BGP-LS will not be allowed for this IGP protocol extension”.
>>>>>
>>>>> IDR WG could say “we would rather you incorporated the BGP-LS
>>>>> extensions directly into the corresponding LSR draft”.
>>>>>
>>>>> But, I don’t hear you saying that. I hear you saying the IDR WG may
>>>>> decide to forbid BGP-LS extensions for this particular IGP extension.
>>>>>
>>>>> Which is why I ask – where is the definition of how such a decision is
>>>>> made?
>>>>>
>>>>>
>>>>>
>>>>> I deliberately am not commenting inline to your response because (no
>>>>> offense intended) nothing in your response is applicable to my question.
>>>>>
>>>>>
>>>>>
>>>>>    Les
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From:* Susan Hares <[e-mail]>
>>>>> *Sent:* Tuesday, June 7, 2022 4:34 PM
>>>>> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Aijun Wang <
>>>>> [e-mail]>
>>>>> *Cc:* [e-mail]
>>>>> *Subject:* RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
>>>>> call (6/6 to 6/20)
>>>>>
>>>>>
>>>>>
>>>>> Les:
>>>>>
>>>>>
>>>>>
>>>>> The IDR and LSR WG chairs have agreed that LSR/BGP BGP-LS
>>>>> specifications often specify the same TLVs.   In this case, if the authors
>>>>> desire, the LSR specification can specify both ISIS TLVs, OSPF TLVs, and
>>>>> BGP-LS TLVS.
>>>>>
>>>>>
>>>>>
>>>>> As part of the WG LC process for such a combination document, the IDR
>>>>> WG reviews BGP-LS portion of the LSR Specification.  If there is an
>>>>> objection to the LSR work going into BGP, then the LSR and IDR chairs
>>>>> handle the issue.  You may have noticed this happening in the past.  Or it
>>>>> may have been part of the LSR chairs back-end process you did not see.
>>>>>
>>>>>
>>>>>
>>>>> For this draft, the authors requested a separate draft would be
>>>>> adopted and WG LC in IDR. Given the author’s request, I must follow the
>>>>> normal procedure for any IDR draft.   As you have notice from Aijun and
>>>>> Robert, there is growing concern the continued addition of BGP-LS TLVs.
>>>>> This growing concern for this draft may have been expressed even if this
>>>>> was a cross-reviewed draft.
>>>>>
>>>>>
>>>>>
>>>>> Consensus decision-making does take time and cross reviews.
>>>>>
>>>>>
>>>>>
>>>>> I hope this helps you understand the administrative process.  The LSR
>>>>> and IDR chairs are trying to minimize needless drafts while providing
>>>>> opportunities for the two WGs to review the documents.
>>>>>
>>>>>
>>>>>
>>>>> Cheers, Sue
>>>>>
>>>>>
>>>>>
>>>>> *From:* Les Ginsberg (ginsberg) <[e-mail]>
>>>>> *Sent:* Tuesday, June 7, 2022 6:57 PM
>>>>> *To:* Susan Hares <[e-mail]>; Aijun Wang <
>>>>> [e-mail]>
>>>>> *Cc:* [e-mail]
>>>>> *Subject:* RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
>>>>> call (6/6 to 6/20)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sue –
>>>>>
>>>>>
>>>>>
>>>>> Color me confused.
>>>>>
>>>>>
>>>>>
>>>>> We have here a protocol extension to IS-IS that the LSR WG has
>>>>> approved (passed last call). Which there was sufficient belief in the WG
>>>>> that this protocol extension was useful for it to be approved.
>>>>>
>>>>> But you claim there is some secondary process, managed by the IDR
>>>>> chairs (or perhaps IDR and LSR chairs?), that determines whether the BGP-LS
>>>>> extensions in support of the approved IGP extensions will be allowed?
>>>>>
>>>>> This is completely new to me – please explain how that process works.
>>>>>
>>>>>
>>>>>
>>>>> NOTE: I am not debating Aijun’s remark as to the “enthusiasm” showed
>>>>> in the LSR WG for the draft – nor was I a vocal supporter of the LSR draft
>>>>> in question.
>>>>>
>>>>> But, if LSR WG approval is not sufficient to justify the corresponding
>>>>> BGP-LS support, please explain what is the defined process and where it is
>>>>> documented and describe how it has been used in the past.
>>>>>
>>>>>
>>>>>
>>>>> Thanx.
>>>>>
>>>>>
>>>>>
>>>>>     Les
>>>>>
>>>>>
>>>>>
>>>>> *From:* Idr <[e-mail]> *On Behalf Of *Susan Hares
>>>>> *Sent:* Tuesday, June 7, 2022 1:54 PM
>>>>> *To:* Aijun Wang <[e-mail]>
>>>>> *Cc:* [e-mail]
>>>>> *Subject:* Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
>>>>> call (6/6 to 6/20)
>>>>>
>>>>>
>>>>>
>>>>> Aijun:
>>>>>
>>>>>
>>>>>
>>>>> Thank you for your feedback on deployment issues.   It is important to
>>>>> know if an operator feels this option will not be deployed.
>>>>>
>>>>>
>>>>>
>>>>> I  will contact other operators to ask them to comment on this
>>>>> adoption call.
>>>>>
>>>>>
>>>>>
>>>>> Sue
>>>>>
>>>>>
>>>>>
>>>>> *From:* Aijun Wang <[e-mail]>
>>>>> *Sent:* Tuesday, June 7, 2022 10:51 AM
>>>>> *To:* Susan Hares <[e-mail]>
>>>>> *Cc:* [e-mail]
>>>>> *Subject:* Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption
>>>>> call (6/6 to 6/20)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi, all:
>>>>>
>>>>>
>>>>>
>>>>> I don’t support its adoption.
>>>>>
>>>>> The corresponding IS-IS document past just the LSR WG unconvincingly
>>>>> and I cannot foresee which operator will deploy the flood reflection
>>>>> mechanism in IS-IS deployment.
>>>>>
>>>>> Then it is doubtful also the corresponding BGP-LS extension.
>>>>>
>>>>> There is no any description for the necessary in the document.
>>>>>
>>>>>
>>>>>
>>>>> If the authors insist to do so, I recommend to incorporate the trivia
>>>>> contents into the corresponding IS-IS document.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Aijun Wang
>>>>>
>>>>> China Telecom
>>>>>
>>>>>
>>>>>
>>>>> On Jun 7, 2022, at 05:28, Susan Hares <[e-mail]> wrote:
>>>>>
>>>>> 
>>>>>
>>>>> This begins a 2 week WG adoption call for
>>>>> draft-head-idr-bgp-ls-isis-fr-01.txt
>>>>>
>>>>>
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-head-idr-bgp-ls-isis-fr/
>>>>>
>>>>>
>>>>>
>>>>>   This document defines one new BGP-LS (BGP Link-State) TLV for
>>>>>
>>>>>    Flood Reflection to match the ISIS TLV for flood reduction.
>>>>>
>>>>>
>>>>>
>>>>>    The draft is short (5 total pages).
>>>>>
>>>>>
>>>>>
>>>>> Since this BGP-LS feature has been adopted by IS-IS,
>>>>>
>>>>> Please consider
>>>>>
>>>>>
>>>>>
>>>>>    1. Is there any technical difficulty with adding this to the
>>>>>    BGP-LS code points?
>>>>>
>>>>> 2.   Is this draft ready for publication?
>>>>>
>>>>> 3.   Does this addition help operational networks.
>>>>>
>>>>>
>>>>>
>>>>> Cheers, Sue Hares
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Idr mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>
>>>>> _______________________________________________
>>>>> Idr mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>>
>>>> _______________________________________________
>>>> Idr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/idr
>>>>
>>>