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

[Robert Raszuk <[e-mail]>]

Hi Tom,

Just one clarification ...

>  too many ways of doing the same thing

This discussion is not about accomplishing the same thing both with IGP and
BGP. This discussion (generally about BGP-LS) is about mandating BGP to
carry IGP info for services invented in IGP to even work.

And not only carry ... to understand every bit of it, parse it, check it,
pack it, send it etc ... BGP hop by BGP hop.

And not only when you invent new stuff. Every time you do enhancement or
even bug fix you need to do the same twice in IGP and in BGP as one seems
useless without the other for end users.

This circle IMO really needs to be discussed and steps taken to break this
loop.

Best,
R.












On Wed, Jun 8, 2022 at 5:43 PM tom petch <[e-mail]> wrote:

> From: Idr <[e-mail]> on behalf of Jordan Head <jhead=
> [e-mail]>
> Sent: 07 June 2022 20:12
>
> Hi Acee, Les,
>
> Good suggestion, happy to make the title more explicit on the next version
> of the draft.
>
> <tp>
>
> Loading up an identifier with lots of semantics rendering it cumbersome
> is  a pet hate of mine, but you have already done that:-(  At least it is
> only an ephemeral name that vanishes and has no relevance once a
> specification becomes an RFC
>
> Changing the name to another one is even worse.  It makes it hard to track
> what the history of an I-D is.  You need to know where to look on the IETF
> website to find the old names.  I have known ADs who failed the test and
> did not find the early versions of an I-D at Last Call.
>
> In this case,  it could make it hard to find the discussion about adoption
> which seems to be as much against as for.  I echo the thought that the
> protocols have got themselves into a tangle, too many ways of doing the
> same thing, and while the marketplace will decide, that can take several
> years and leave some frustrated that what was obviously the best approach
> has fallen by the wayside.
>
> Tom Petch
>
> Thanks
>
> From: Idr <[e-mail]> on behalf of "Acee Lindem (acee)" <acee=
> [e-mail]>
> Date: Tuesday, June 7, 2022 at 10:45 AM
> To: "Les Ginsberg (ginsberg)" <ginsberg=[e-mail]>,
> Susan Hares <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call
> (6/6 to 6/20)
>
> [External Email. Be cautious of content]
>
> I agree – for many of us, “fr” will always bring frame relay to mind first…
> Acee
>
> From: "Les Ginsberg (ginsberg)" <ginsberg=[e-mail]>
> Date: Tuesday, June 7, 2022 at 10:42 AM
> To: Acee Lindem <[e-mail]>, Susan Hares <[e-mail]>, IDR List
> <[e-mail]>
> Subject: RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call
> (6/6 to 6/20)
>
> I also support adoption.
>
> Regarding the draft name, “fr” is quite cryptic and somewhat ambiguous.
>
> “draft-head-idr-bgp-ls-isis-flood-reflection” would align the name with
> the LSR draft – but if that is considered too long maybe
> “draft-head-idr-bgp-ls-isis-freflect” ??
>
>    Les
>
>
> From: Idr <[e-mail]> On Behalf Of Acee Lindem (acee)
> Sent: Tuesday, June 7, 2022 5:32 AM
> To: Susan Hares <[e-mail]>; [e-mail]
> Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call
> (6/6 to 6/20)
>
> I support WG adoption – the corresponding LSR draft has completed WG last
> call and is awaiting AD review.
>
> Thanks,
> Acee
>
> From: Idr <[e-mail]<mailto:[e-mail]>> on behalf
> of Susan Hares <[e-mail]<mailto:[e-mail]>>
> Date: Monday, June 6, 2022 at 5:28 PM
> To: IDR List <[e-mail]<mailto:[e-mail]>>
> Subject: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to
> 6/20)
>
> 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/<
> https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-head-idr-bgp-ls-isis-fr/__;!!NEt6yMaO-gk!CafxHn3pbZysrIyVSxj84fABHpIaBa6N9ARiX1QpzY1aZZA_zdNvXbzlu0c5O_XryeexWrPa3CclpsKqYxOn2MWio074HA$
> >
>
>   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
>
>
>
>
>
> Juniper Business Use Only
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>