I think that, before jumping in to criticise draft-dong-spring-sr-for-enhanced-vpn too much for the *potential* for state explosion, everyone should read draft-ietf-teas-enhanced-vpn and draft-dong-teas-enhanced-vpn-vtn-scalability with some care (as Pavan appears to have done :-) to see the difference between a slice and a slice. The VTN construct is a virtual network topology with associated resources (a macro slice, if you like) that can support multiple network slices or enhanced VPNs that are subject to the same class of treatment (micro slices, perhaps). The number of VTNs need not be large although, my understanding is that the authors do not prevent operators from deciding to shoot themselves.
One could, if so minded, call the VTN a "slice aggregate". Cheers, Adrian -----Original Message----- From: spring <spring-boun...@ietf.org> On Behalf Of Joel M. Halpern Sent: 02 February 2021 19:54 To: Colby Barth <barth.co...@gmail.com>; spring@ietf.org Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn Colby, you are, as far as I can tell, correct that the potential for state explosion is extremely risky and requires careful management. That is why the bestbar draft emphasis that the state is abotu slice aggregates, not end-to-end slices, and probably not even individual IETF network slices. Yours, Joel On 2/2/2021 2:19 PM, Colby Barth wrote: > Tarek, indeed … > > draft-bestbar-spring-scalable-ns-00 provides a relevant example of the rather > enormous amount of state the solution described in > draft-dong-spring-sr-for-enhanced-vpn results in: > > "Notably, this approach requires maintaining per slice state for each > topological element on every router in the network in both the > control and data plane. For example, a network composed of 'N' > nodes, where each node has up to 'K' adjacencies to its neighbors, a > node would have to assign and advertise 'M' Slice Prefix-SIDs and 'M' > Slice Adjacency-SID(s) to each of it 'K' adjacencies. Consequently, > a router will have to maintain up to (N+K)*M SIDs in the control > plane, and an equal number of label routes in its forwarding plane." > > > Put in practical terms, this implicitly limits the number of VTNs or, in > draft-bestbar-teas-ns-packet-01 terminology, the number of Slice aggregates > that can be offered. It also introduces a dependency between the network > size and the number of VTNs. i.e. the larger the network, the smaller the > number of VTNs that can be supported. > > —Colby > >> On Feb 2, 2021, at 12:54 PM, Tarek Saad <tsaad=40juniper....@dmarc.ietf.org> >> wrote: >> >> Hi Eduard, >> >> Inline.. >> >> On 2/2/21, 10:50 AM, "spring on behalf of Vasilenko Eduard" >> <spring-boun...@ietf.org on behalf of vasilenko.edu...@huawei.com> wrote: >> >> Hi all, >> There is the general trend to encode the action into the packet, not to >> distribute states in the control plane for all possible traffic types. >> Granularity, programmability are better. >> >> [TS]: Indeed, we are in agreement on encoding the information in packet as >> opposed to distributing states in the control plane. In >> draft-bestbar-spring-scalable-ns, a separate ID inside the packet is >> proposed to carry the needed information. However, this draft >> <draft-dong-spring-sr-for-enhanced-vpn> is proposing distributing per VTN >> state in the network which is completely against your argument ... >> >> Regards, >> Tarek >> >> >> >> This type of virtualization is fully in-line with this trend. >> Support. >> Eduard >> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard >> Sent: Wednesday, January 27, 2021 12:47 PM >> To: spring@ietf.org >> Cc: spring-cha...@ietf.org >> Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn >> >> Dear WG: >> >> This message starts a 2 week WG adoption call for >> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ >> ending February 10th 2021. >> >> After review of the document please indicate support (or not) for WG >> adoption to the mailing list and if you are willing to work on the document, >> please state this explicitly. This gives the chairs an indication of the >> energy level of people in the working group willing to work on this >> document. Please also provide comments/reasons for your support (or lack >> thereof) as this is a stronger way to indicate your (non) support as this is >> not a vote. >> >> Thanks! >> >> Jim, Bruno & Joel >> >> >> >> >> Juniper Business Use Only >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
