Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Gyan Mishra]

I support WG adoption as this draft helps maintain feature parity as close
as possible  between OSPF and ISIS.

Great job on the continuing effort to  maintaining IGP feature parity by WG
and chairs.

This is very important for operators.

ISIS MI RFC 8202
OSPFv3 AF RFC 5838

ISIS Advertise Generic Information RFC 6824
OSPFv2 OSPFv3 transport instance - this draft

As Robert mentioned and I think others agree that there is some parity that
can be extended from IGP to EGP.

Kind Regards

Gyan

On Sun, May 2, 2021 at 4:47 AM Christian Hopps  wrote:

>
> This begins a 2 week WG adoption call for the following draft:
>
>
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
>
> Please indicate your support or objection by May 16th, 2021.
>
> Authors, please respond to the list indicating whether you are aware of
> any IPR that applies to this draft.
>
> Historical Note: The original OSPF transport instance document was adopted
> by the OSPF WG back in 2009, it was last updated in 2014, and then revived
> as an individual submission to LSR in Sep 2020. :)
>
> Thanks,
> Chris.
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG Adoption Poll for “Using IS-IS Multi-Topology (MT) for Segment Routing based Virtual Transport Network” - draft-xie-lsr-isis-sr-vtn-mt-03

[Gyan Mishra]

Thanks Tony for the valuable feedback!!

Gyan

On Mon, Mar 29, 2021 at 2:59 AM Tony Przygienda  wrote:

> I never saw more than 3-4 MT "slices" deployed, Gyan. Operational
> complexity basically. Usual Ks or 10Ks prefixes in main instance and not
> more than maybe 1K in others.
>
> So practically speaking I would worry about operational procedures of such
> a deployment first (OAM, connected topologies, provisioning [since both
> sides of MT need matching configuration, as I said, on purpose from
> experience operating such things then], validation). A controller makes a
> lot sense here, not even necessarily as provisioning tool first but
> visualization, OAM, operational analytics. Think basically that you're
> getting yourself from "normal IGP" experience into something that will
> resemble L3VPN more and you know the problems there pretty well ;-)
>
> Also, planning of fast reroute strategy is good, what links/mix of
> topologies you want to protect others and will you have enough capacity
> once FRR kicks in. There are commercial tools available to "simulate" that
> kind of stuff and AFAIR decent amount of theoretical work done on necessary
> algorithms (and since the solution space starts to become real large real
> fast something like an A/B test with ML could deliver good results [weighed
> decision trees or something like this]. The difficult thing being of course
> to establish a cost function as in "is one topology down due to overload &
> e'one protected without loss better than e'one losing some packets better
> or worse").
>
> --- tony
>
>
>
> On Mon, Mar 29, 2021 at 7:07 AM Gyan Mishra  wrote:
>
>> Hi  Tony
>>
>> One of the main concerns for operators as you have elaborated is the real
>> world operators experiences aside from what you mentioned common use case
>> of IPv6 as the first non zero MT, and vendor feedback on scalability and
>> resource issues using many MT IPv4 and IPv6 separate instance and how well
>> it scales or not and operational impacts with troubleshooting multiple RIB
>> instances with common LSDB with discrete SPF instance per topology and
>> control plane scale issues as the number of instances grows.
>>
>> Also complexity related to NOC troubleshooting and MTTR when you have
>> let’s say 10 to 100 network slices for example, how complex do things get
>> and is it manageable or not.
>>
>> As you have 12 bits of MT ID, 4096 instances is quite a lot.  Could you
>> really ever scale to 4096 MT instances, probably not.
>>
>> What is a real world practical hard limit from your experiences of number
>> of prefixes per MT RIB and maximum number of MT RIB instances.
>>
>> Also a cross comparison of MI non zero instance IID/ITID comparing 100
>> ITID sub topologies to 100 MT RIB topologies and which scales better.
>>
>> Much appreciated your MT & MI experiences  and real world feedback.
>>
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Mar 27, 2021 at 6:59 AM Tony Przygienda 
>> wrote:
>>
>>> Having had a long history with RFC5120 (and with the concept before IETF
>>> was even afoot really) and their deployment in its time I cannot resist
>>> finally chiming in a bit ;-)
>>>
>>> Well, first, it seems there is agreement that the drafts state fairly
>>> straightforward things but as informational probably nothing wrong with
>>> having it captured and I'd agree with that.
>>>
>>> Second, as to realities of MT in such architecture some musings based on
>>> experience;
>>>
>>> a) MT was best used when faced with the problem of "alien" topologies,
>>> e.g. introduction of v6 into a network when a lot of boxes/links couldn't
>>> do v6 yet (there was a good set of discussions in its time around MT
>>> strictly per node or per link being best approach and for many reasons link
>>> based architecture was chosen) or need for drastically different forwarding
>>> decision deviating from simple SPF (RPF problems).
>>> b) using underlay to "slice" is an expensive proposition of course. The
>>> costliest resources in large networks is really ASIC space in the core and
>>> if the MTs are properly separated, that will take ASIC state. in simplest
>>> form e.g. topology being mirrored into per DSCP bits lookup or something
>>> like this. Nothing wrong with that if one has the $ (or CNY ;-) to foot the
>>> bill for that and slicing underlay gives of course the best quality
>>> assurance compared to overlay approaches AFAIS.
>>> c) MT (well, at least in ISIS ;-) has been built to scale ;-),
>>> originally 8 bits were suggested and then I asked others "what's the
>>> biggest you can imagine" to which answer was 1024 MT which needed of course
>>> a multiplication by 4 to make sure stuff will still work in 25 years where
>>> we are today ;-)
>>> d) SPF is to an extent only limitation of MT. the tree itself can be
>>> computed very efficiently today (and there are techniques like incremental
>>> SPF which can drastically lessen the cost of a computation and one can go
>>> to the extent of throwing the 

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Huaimo Chen]

Support its adoption.

Best Regards,
Huaimo

From: Lsr  on behalf of Christian Hopps 

Sent: Sunday, May 2, 2021 4:39 AM
To: lsr@ietf.org 
Cc: lsr-...@ietf.org ; cho...@chopps.org ; 
draft-acee-lsr-ospf-transport-insta...@ietf.org 

Subject: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02


This begins a 2 week WG adoption call for the following draft:


https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-ospf-transport-instance%2Fdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Ca5078f2677c44f70a6a008d90d46e4f8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637555420448681736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ikn6KJzPpEt%2BZcBHgM0oVJLWXzqGka85Tr2ztsV%2BHiw%3Dreserved=0

Please indicate your support or objection by May 16th, 2021.

Authors, please respond to the list indicating whether you are aware of any IPR 
that applies to this draft.

Historical Note: The original OSPF transport instance document was adopted by 
the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
individual submission to LSR in Sep 2020. :)

Thanks,
Chris.

___
Lsr mailing list
Lsr@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsrdata=04%7C01%7Chuaimo.chen%40futurewei.com%7Ca5078f2677c44f70a6a008d90d46e4f8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637555420448681736%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=1NOK2MXK7LXMjpA%2F9z8MA%2FJ%2FvFYGmjcA%2BjjE1MfipdI%3Dreserved=0
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Robert Raszuk]

Support.

Happy to see LSR thinking ahead.

Wish IDR would do the same in respect to minimise the impact of non routing
stuff with "Transport Instance BGP" draft I proposed 10+ years back ... :(
https://tools.ietf.org/html/draft-raszuk-ti-bgp-01

Best,
R.



On Sun, May 2, 2021 at 11:19 PM Les Ginsberg (ginsberg)  wrote:

> I support WG adoption.
>
> The use of IGP flooding to distribute information unrelated to the
> operation of the protocol negatively impacts the operation of the protocol
> in support of its primary function - L3 routing.
> Although I favor discouraging using the protocol in this way, in the event
> such uses cases are defined, there needs to be a way to minimize the impact
> - which this draft provides.
>
>Les
>
> > -Original Message-
> > From: Lsr  On Behalf Of Christian Hopps
> > Sent: Sunday, May 02, 2021 1:39 AM
> > To: lsr@ietf.org
> > Cc: lsr-...@ietf.org; cho...@chopps.org; draft-acee-lsr-ospf-transport-
> > insta...@ietf.org
> > Subject: [Lsr] WG adoption call for
> draft-acee-lsr-ospf-transport-instance-02
> >
> >
> > This begins a 2 week WG adoption call for the following draft:
> >
> >
> https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
> >
> > Please indicate your support or objection by May 16th, 2021.
> >
> > Authors, please respond to the list indicating whether you are aware of
> any
> > IPR that applies to this draft.
> >
> > Historical Note: The original OSPF transport instance document was
> adopted
> > by the OSPF WG back in 2009, it was last updated in 2014, and then
> revived as
> > an individual submission to LSR in Sep 2020. :)
> >
> > Thanks,
> > Chris.
> >
> > ___
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] WG adoption call for draft-acee-lsr-ospf-transport-instance-02

[Jeff Tantsura]

Yes/support 

Regards,
Jeff

> On May 2, 2021, at 01:47, Christian Hopps  wrote:
> 
> 
> This begins a 2 week WG adoption call for the following draft:
> 
>   https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
> 
> Please indicate your support or objection by May 16th, 2021.
> 
> Authors, please respond to the list indicating whether you are aware of any 
> IPR that applies to this draft.
> 
> Historical Note: The original OSPF transport instance document was adopted by 
> the OSPF WG back in 2009, it was last updated in 2014, and then revived as an 
> individual submission to LSR in Sep 2020. :)
> 
> Thanks,
> Chris.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr