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

[Tony Przygienda <[e-mail]>]

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