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

[Tony Przygienda <[e-mail]>]

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
>