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:lsr-boun...@ietf.org] On Behalf Of Gyan Mishra
Sent: Monday, March 8, 2021 7:29 AM
To: Tony Przygienda <tonysi...@gmail.com>
Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; Chongfeng 
Xie <chongfeng....@foxmail.com>; Acee Lindem (acee) <a...@cisco.com>; Robert 
Raszuk <rob...@raszuk.net>; lsr@ietf.org
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 
<tonysi...@gmail.com<mailto:tonysi...@gmail.com>> 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
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr
--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

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

Reply via email to