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

[Tony Przygienda <[e-mail]>]

This argument seems fairly bogus to me. if you use IGP to flood some stuff
and then want the distributed computation stitch it together based on IGP
topology to get you a nexthop you end in computation which is something
like Bellman or Dijkstra or Boruvka. Unless you have some controller
distributing next-hops but then it's really PCE and not IGP AFAIS.

The difference in MI and MT is that MT carries the topology information
everywhere (you don't have to compute if you're not part of [simple check
on adjacencies] it but you still get stuff flooded). Some people like that
(manageability), some don't. IS does only flood to nodes connected in MI.

Operationally I learned ages ago that topologies disconnecting are some of
the most vexing scenarios and there MT is @ an advantage since partitioned
topology can be easily derived (and that's BTW why it's built that way with
strict adjacency negotiation). Reading the bestbar draft and looking @ e.g.
flex algo I am waiting to see how the "I cannot get there, why?" problems

On Mon, Mar 8, 2021 at 3:43 PM Tarek Saad <[e-mail]> wrote:

> Hi authors,
>
>
>
> My understanding is the draft is proposing a separate MT topology (unique
> MT-ID) to identify a forwarding treatment to be enforced on a shared
> resource.
>
> While this may work for limited number of MT topologies (i.e. forwarding
> treatments), as described in RF5120 there is overhead with
> creating/advertising and managing and running separate SPF for each of the
> MT topology. This will restrict the scalability of such approach (number of
> forwarding treatments to be realized) using this approach.
>
>
>
> In I-D.draft-bestbar-lsr-spring-sa we are proposing carrying an
> independent ID (associated with the forwarding treatment) independent of
> the topology ID. This allows the # of forwarding treatmentst to be
> independent of the # of MT topologies that need to be managed by IGP; and
> hence, allow it to scale. Your feedback on this approach is welcome.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
> On 3/8/21, 9:29 AM, "Lsr on behalf of Dongjie (Jimmy)" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>
>
> Hi Gyan,
>
>
>
> Thanks for your comments.
>
>
>
> As you mentioned, both MT and MI can provide separate topologies and the
> topology based computation, and MI can provide separate LSDBs at some
> additional cost (separate adjacencies, etc.). In this document, the
> resource of VTN mainly refers to the forwarding plane resources, thus MT is
> chosen as it can provide the required functionality with less overhead.
>
>
>
> Hope this helps.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Lsr [mailto:[e-mail]] *On Behalf Of *Gyan Mishra
> *Sent:* Monday, March 8, 2021 7:29 AM
> *To:* Tony Przygienda <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <ginsberg=[e-mail]>;
> Chongfeng Xie <[e-mail]>; Acee Lindem (acee) <
> [e-mail]>; Robert Raszuk <[e-mail]>; [e-mail]
> *Subject:* 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
>
>
>
>
>
> Dear Authors
>
>
>
> Why was MT chosen and not MI for VTN underlay network slice underpinning.
> MT instances has separate topology but not separate LSDB where MI Multi
> instance RFC 6822 has a separate LSDB for resources isolation and I think
> would be a better fit for VTN underlay provisioning.
>
>
>
> MI
>
> https://tools.ietf.org/html/rfc6822
>
>
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Sun, Mar 7, 2021 at 10:34 AM Tony Przygienda <[e-mail]>
> wrote:
>
>
>
> Robert ruminated:
>
>
>
> That said I think perhaps we are indeed missing LROW WG (Local Routing
> Operations WG) where just like in GROW WG where mainly (Global) BGP
> operational aspects are discussed there could be good place to discuss
> operational aspects of link state protocols deployment and use cases. In
> fact perhaps it would also free some LSR bandwidth to really focus on
> protocol extensions.
>
>
>
>
>
> +1
>
>
>
> IGPs grew a zoo of horns and bells by now and no'one tells the operators
> which spines are poisonous ;-)
>
>
>
> --- tony
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
>
>
> *M 301 502-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> Juniper Business Use Only
>