Hi Jie,
Now that you mention VTN-ID, I have to point out that the VTN-ID in
draft-dong-lsr-sr-for-enhanced-vpn is actually the AII in
draft-peng-teas-network-slicing, just a new name. That can be seen from the
evolution of the historical versions of the these two drafts.
See https://mailarchive.ietf.org/arch/msg/spring/sgyRpAW5kzcUCdat9FtW15PPbRM/
I'm glad to see that the idea in draft-peng-teas-network-slicing and
draft-bestbar-spring-scalable-ns have been generously adopted by you.
Regards,
PSF
原始邮件
发件人：Dongjie(Jimmy)
收件人：Tarek Saad;Gyan Mishra;Tony Przygienda;
抄送人：Les Ginsberg (ginsberg);Chongfeng Xie;Acee Lindem (acee);Robert
Raszuk;[email protected];
日 期 ：2021年03月09日 00:31
主 题 ：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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
Hi Tarek,
Your understanding about the scalability implication of this MT based VTN
mechanism is correct, this is also described in section “scalability
considerations” of this draft. The value of this mechanism is that it reuses
several existing TLVs together to provide the required function.
As for the mechanisms which can provide better scalability, you could refer to
draft-dong-lsr-sr-for-enhanced-vpn, in which a new control plane VTN-ID is
introduced, and multiple VTNs can be associated with the same topology. Further
discussion about that draft and its relationship with
draft-bestbar-lsr-spring-sa could happen in a separate thread.
Best regards,
Jie
From: Tarek Saad [mailto:[email protected]]
Sent: Monday, March 8, 2021 10:44 PM
To: Dongjie (Jimmy) <[email protected]>; Gyan Mishra
<[email protected]>; Tony Przygienda <[email protected]>
Cc: Les Ginsberg (ginsberg) <[email protected]>; Chongfeng
Xie <[email protected]>; Acee Lindem (acee) <[email protected]>; Robert
Raszuk <[email protected]>; [email protected]
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
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)" <[email protected] on
behalf of [email protected]> 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:[email protected]] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda <[email protected]>
Cc: Les Ginsberg (ginsberg) <[email protected]>; Chongfeng
Xie <[email protected]>; Acee Lindem (acee) <[email protected]>; Robert
Raszuk <[email protected]>; [email protected]
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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
--
Gyan Mishra
Network Solutions Architect
M 301 502-1347
13101 Columbia Pike
Silver Spring, MD
Juniper Business Use Only
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
