Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01

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 <tonysietf@gmail.com> 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 <robert@raszuk.net> 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 <shares@ndzh.com>
>>> *Sent:* Tuesday, June 7, 2022 5:58 PM
>>> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Aijun Wang <
>>> wangaijun@tsinghua.org.cn>
>>> *Cc:* idr@ietf.org
>>> *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) <ginsberg@cisco.com>
>>> *Sent:* Tuesday, June 7, 2022 8:01 PM
>>> *To:* Susan Hares <shares@ndzh.com>; Aijun Wang <
>>> wangaijun@tsinghua.org.cn>
>>> *Cc:* idr@ietf.org
>>> *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 <shares@ndzh.com>
>>> *Sent:* Tuesday, June 7, 2022 4:34 PM
>>> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Aijun Wang <
>>> wangaijun@tsinghua.org.cn>
>>> *Cc:* idr@ietf.org
>>> *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) <ginsberg@cisco.com>
>>> *Sent:* Tuesday, June 7, 2022 6:57 PM
>>> *To:* Susan Hares <shares@ndzh.com>; Aijun Wang <
>>> wangaijun@tsinghua.org.cn>
>>> *Cc:* idr@ietf.org
>>> *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 <idr-bounces@ietf.org> *On Behalf Of *Susan Hares
>>> *Sent:* Tuesday, June 7, 2022 1:54 PM
>>> *To:* Aijun Wang <wangaijun@tsinghua.org.cn>
>>> *Cc:* idr@ietf.org
>>> *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 <wangaijun@tsinghua.org.cn>
>>> *Sent:* Tuesday, June 7, 2022 10:51 AM
>>> *To:* Susan Hares <shares@ndzh.com>
>>> *Cc:* idr@ietf.org
>>> *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 <shares@ndzh.com> 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
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>>> _______________________________________________
>>> Idr mailing list
>>> Idr@ietf.org
>>> https://www.ietf.org/mailman/listinfo/idr
>>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>

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