Hi, As Joel notes, it is true that enhanced VPNs require the use of specific underlay network resources, either dedicated or shared, but the this needs to be done without installing overlay VPN awareness in the P routers, which is inherently unscalable and operationally complex. Also, since VPNs span multiple ASes, putting overlay VPN state in an IGP doesn't work.
Please see: https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn-02 Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Joel M. Halpern > Sent: Thursday, March 26, 2020 9:36 AM > To: xie...@chinatelecom.cn; lsr <lsr@ietf.org> > Subject: Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing based > Virtual Transport Network > > [External Email. Be cautious of content] > > > In once sense, the statement is inherently true. A VPN technology without > underlay support would seem to have significant difficulty in consistently > meeting an SLA. Having said that much, the rest does not seem to follow. > > Yours, > Joel > > On 3/26/2020 1:40 AM, xie...@chinatelecom.cn wrote: > > > > Hi, Joel, > > > > The statement is that pure overlay VPNs cannot meet the requirement of > > some new services, and it would require integration between the > > underlay and the overlay networks. > > > > As mentioned in this document, there is existing technology in the > > underlay to support enhanced VPNs , such as using a set of MPLS-TE > > based resource reserved point-to-point paths, while it scalability is > > the concern of many operators. > > > > Thus VTN is introduced to provide the required topology and resource > > attribute in the underlay in a scalable manner. This is described in > > the introduction section. > > > > Hope this helps. > > > > > > Chongfeng > > > > > > *From:* Joel M. Halpern <mailto:j...@joelhalpern.com> > > *Date:* 2020-03-25 21:52 > > *To:* xie...@chinatelecom.cn <mailto:xie...@chinatelecom.cn>; lsr > > <mailto:lsr@ietf.org> > > *Subject:* Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment > > Routing based Virtual Transport Network > > This drafts starts by asserting that there are limitations on what can > > be done with the existing technology. As the description is quite > > vague, I can not be certain. But I do not know of any difficulty in > > providing the described capabilities with current technology, without > > introducing a new, undescribed, construct called a VTN. > > Yours, > > Joel > > On 3/25/2020 9:44 AM, xie...@chinatelecom.cn wrote: > > > > > > Hello, folks, > > > > > > we have submitted a new draft of > > > > > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-xie-lsr- > isis-sr-vtn-mt-00__;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu-- > 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyXyHvpt8$ . > > > > > > It is about Using IS-IS Multi-Topology (MT) for Segment Routing > > based > > > Virtual Transport Network. Enhanced VPN (VPN+) as defined in > > > I-D.ietf-teas-enhanced-vpn aims to provide enhanced VPN service to > > > support some applications's needs of enhanced isolation and > > stringent > > > performance requirements. VPN+ requries integration between the > > overlay > > > VPN and the underlay network. A Virtual Transport Network (VTN) > > is a > > > virtual network which consists of a subset of the network toplogy > > and > > > network resources allocated from the underlay network. A VTN > > could be > > > used as the underlay for one or a group of VPN+ services.. This > > document > > > describes a simplified mechanism to build the SR based VTNs using > > IGP > > > multi- topology together with other well-defined IS-IS extensions. > > > > > > Comments and suggestions are highly appreciated. > > > > > > Chongfeng Xie > > > > > > > > > > > > _______________________________________________ > > > Lsr mailing list > > > Lsr@ietf.org > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt > 6yMaO-gk!UC57ahoSTr0MI_h20crJfu-- > 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyCiP9TE0$ > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu-- > 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs > > fyCiP9TE0$ > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ > > _;!!NEt6yMaO-gk!UC57ahoSTr0MI_h20crJfu-- > 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bs > > fyCiP9TE0$ > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt > 6yMaO-gk!UC57ahoSTr0MI_h20crJfu-- > 3Q_Skbm0IIKvdcQHjUvsVslOpTl1bsfyCiP9TE0$ _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
