Subject: [Teas] Definitions of VTN and Slice Aggregate in the drafts

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 9 Mar 2021 18:38:26 +0000

Hi all,

In today's meeting, some people raised comments about the confusions caused by the multiple terms. To help the understanding with the term "VTN" and "Slice Aggregate", I reread the text about their definitions and descriptions in each draft.

Although the terminologies are described in different ways, IMO the essential information behind is the same: a logical network construct consists of the topology attribute and the network resources attributes.

Some effort to resolve the terminology overlap could help to reduce the confusions and provide a consistent view on the framework and technologies for network slice realization.

Here are the text about the terms quoted from each draft:

- VTN (in draft-ietf-teas-enhanced-vpn-07):

VPN+ is built from a VPN overlay and an underlying Virtual Transport Network (VTN) which has a customized network topology and a set of dedicated or shared resources in the underlay network.

A VTN is a virtual underlay network that connects customer edge points. The VTN has the capability to deliver the performance characteristics required by an enhanced VPN customer and to provide isolation between separate VPN+ instances.

- Slice Aggregate (in draft-bestbar-teas-ns-packet-02)

This document introduces the notion of a slice aggregate which comprises of one of more IETF network slice traffic streams. It describes how a slice policy can be used to realize a slice aggregate by instantiating specific control and data plane behaviors on select topological elements in IP/MPLS networks.

When logical networks representing slice aggregates are realized on top of a shared physical network infrastructure, it is important to steer traffic on the specific network resources allocated for the slice aggregate.

Slice aggregate: a collection of packets that match a slice policy selection criteria and are given the same forwarding treatment; a slice aggregate comprises of one or more IETF network slice traffic streams; the mapping of one or more IETF network slices to a slice aggregate is maintained by the IETF Network Slice Controller.

- Slice policy (in draft-bestbar-teas-ns-packet-02, to help the understanding of Slice Aggregate)

Slice policy: a policy construct that enables instantiation of mechanisms in support of IETF network slice specific control and data plane behaviors on select topological elements; the enforcement of a slice policy results in the creation of a slice aggregate.

A slice policy topology may include all or a sub-set of the physical nodes and links of an IP/MPLS network; it may be comprised of dedicated and/or shared network resources (e.g., in terms of processing power, storage, and bandwidth).

Best regards,
Jie

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 10 Mar 2021 09:17:47 +0000

Hi Jie,
Clarification on terminology is always a good effort to do  thanks for that.
On the other hand I'd like to understand , about "VTN", what is the difference in your VTN concept with respect what already defined in RFC 8453 in section 2.1?
In that section there is a description also of the two types of VN , customer can manage.
A parallel effort with draft-ietf-teas-actn-vn-yang permits to "create" VN of the desired type.
So my question is : what in your "new" VTN is different with respect what already defined related to VN to force using another term ?

Thanks
Sergio

From: Teas <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: Tuesday, March 9, 2021 7:38 PM
To: [email-masked]
Subject: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi all,

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 11 Mar 2021 09:57:02 +0000

Hi Sergio,

Thanks for your support on the terminology clarification. It is important to have consistent understanding about the terminology before we could understand the relationship between different proposals.

As for the VN concept defined in RFC 8453, to me the concept of VN and VTN looks similar, while they are introduced for different purposes.

VN in RFC 8453 is to provide the customer with an abstracted view of the network based on YANG models. There are two modes to provide such view to customer: abstracted as a set of edge-to-edge links, or abstracted as a topology or virtual nodes and virtual links.

While the term VTN was introduced to refer to the virtual underlay network in the layered architecture as described in draft-ietf-teas-enhanced-vpn, it is used to organize a subset of the network nodes and links, and allocate a set of network resources on these nodes and links to build a customized underlay network. Operator can instantiate multiple VTNs to carry different types of services, or the traffic of different customers. The customers does not necessarily need to be provided with the information of VTN.

Another consideration was that the term VN is generic (not only defined in RFC 8453), thus could mean different things in different context. Thus we choose to use a dedicated term for the virtual underlay network.

Hope this helps.

Best regards,
Jie

From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:[email-masked]]
Sent: Wednesday, March 10, 2021 5:18 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]; Daniele Ceccarelli <[email-masked]>; [email-masked]
Subject: RE: Definitions of VTN and Slice Aggregate in the drafts

Hi Jie,

Thanks
Sergio

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: Tuesday, March 9, 2021 7:38 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi all,

Best regards,
Jie

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Mar 2021 13:41:51 -0000

The line that stand out from this conversation for me is:

> As for the VN concept defined in RFC 8453, to me the concept of VN and VTN
looks similar, while they are introduced for different purposes.

>From my perspective, a VN (ACTN) is a topology carved out of the network and
presented to the ACTN consumer, while a VTN (VPN+) is a topology carved out
of the network for its own use in delivering enhanced VPNs. That looks
pretty much what Jie said: same concept but for different purposes.

FWIW, in draft-king-teas-applicability-actn-slicing we saw ACTN as a
tool/mechanism that could be used to realise a network slice or an enhanced
VPN. That is, it can build the virtual topology that underpins a network
slice.

I think a number of concepts are converging within TEAS. This should be
cause for celebration, although it is not always easy to get full
convergence.

What we found when writing draft-king-teas-applicability-actn-slicing was
that the terminology was not consistent. That, sadly, led us to have to
define some of our own terms. I fully expect that as time progresses we will
see continued convergence on terminology that will cause a number of us to
have to update our drafts.

Cheers,

Adrian

From: Teas <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: 11 March 2021 09:57
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: [email-masked]; Daniele Ceccarelli
<[email-masked]>; [email-masked]
Subject: Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi Sergio, 

Thanks for your support on the terminology clarification. It is important to
have consistent understanding about the terminology before we could
understand the relationship between different proposals.

As for the VN concept defined in RFC 8453, to me the concept of VN and VTN
looks similar, while they are introduced for different purposes.

VN in RFC 8453 is to provide the customer with an abstracted view of the
network based on YANG models. There are two modes to provide such view to
customer: abstracted as a set of edge-to-edge links, or abstracted as a
topology or virtual nodes and virtual links. 

While the term VTN was introduced to refer to the virtual underlay network
in the layered architecture as described in draft-ietf-teas-enhanced-vpn, it
is used to organize a subset of the network nodes and links, and allocate a
set of network resources on these nodes and links to build a customized
underlay network. Operator can instantiate multiple VTNs to carry different
types of services, or the traffic of different customers. The customers does
not necessarily need to be provided with the information of VTN.

Another consideration was that the term VN is generic (not only defined in
RFC 8453), thus could mean different things in different context. Thus we
choose to use a dedicated term for the virtual underlay network. 

Hope this helps. 

Best regards,

Jie

From: Belotti, Sergio (Nokia - IT/Vimercate)
[mailto:[email-masked]] 
Sent: Wednesday, March 10, 2021 5:18 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: [email-masked]; Daniele Ceccarelli <[email-masked]>;
[email-masked]
Subject: RE: Definitions of VTN and Slice Aggregate in the drafts

Hi Jie,

On the other hand I'd like to understand , about "VTN", what is the
difference in your VTN concept with respect what already defined in RFC 8453
in section 2.1? 

In that section there is a description also of the two types of VN ,
customer can manage.

A parallel effort with draft-ietf-teas-actn-vn-yang permits to "create" VN
of the desired type. 

So my question is : what in your "new" VTN is different with respect what
already defined related to VN to force using another term ? 

Thanks 

Sergio

 

From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf
Of Dongjie (Jimmy)
Sent: Tuesday, March 9, 2021 7:38 PM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi all, 

In today's meeting, some people raised comments about the confusions caused
by the multiple terms. To help the understanding with the term "VTN" and
"Slice Aggregate", I reread the text about their definitions and
descriptions in each draft. 

Although the terminologies are described in different ways, IMO the
essential information behind is the same: a logical network construct
consists of the topology attribute and the network resources attributes.

Some effort to resolve the terminology overlap could help to reduce the
confusions and provide a consistent view on the framework and technologies
for network slice realization.

VPN+ is built from a VPN overlay and an underlying Virtual Transport Network
(VTN) which has a customized network topology and a set of dedicated or
shared resources in the underlay network.

A VTN is a virtual underlay network that connects customer edge points. The
VTN has the capability to deliver the performance characteristics required
by an enhanced VPN customer and to provide isolation between separate VPN+
instances.

This document introduces the notion of a slice aggregate which comprises of
one of more IETF network slice traffic streams. It describes how a slice
policy can be used to realize a slice aggregate by instantiating specific
control and data plane behaviors on select topological elements in IP/MPLS
networks.

When logical networks representing slice aggregates are realized on top of a
shared physical network infrastructure, it is important to steer traffic on
the specific network resources allocated for the slice aggregate.

Slice aggregate: a collection of packets that match a slice policy selection
criteria and are given the same forwarding treatment; a slice aggregate
comprises of one or more IETF network slice traffic streams; the mapping of
one or more IETF network slices to a slice aggregate is maintained by the
IETF Network Slice Controller.

- Slice policy (in draft-bestbar-teas-ns-packet-02, to help the
understanding of Slice Aggregate)

Slice policy: a policy construct that enables instantiation of mechanisms in
support of IETF network slice specific control and data plane behaviors on
select topological elements; the enforcement of a slice policy results in
the creation of a slice aggregate.

A slice policy topology may include all or a sub-set of the physical nodes
and links of an IP/MPLS network; it may be comprised of dedicated and/or
shared network resources (e.g., in terms of processing power, storage, and
bandwidth).

Best regards,

Jie

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Mon, 15 Mar 2021 12:44:15 +0000

Hi Adrian, Jie,

Thanks for your replies.
Sincerely , while I agree on the fact that VN and VTN are introduced for different purpose, nothing prevent to use the "same" concept for different context as soon as the concept is covering multiple requirement!
So question is again what in VN is preventing to be used in an enhanced VPN.
Adrian underlined that ACTN tool/mechanism is able to provide a network slice and then an enhanced VPN, and so I do not understand why a VN type 2 for example should be different to what Jie described as VTN.
Moreover , for VN, exists already a YANG to create a VN and in parallel a VN service mapping as well, so question is : is this model able to support a VTN as well or, even if for a similar concept , we need to have a separate YANG model ?
A proliferation of different models are not good in my view without real needs.

Thanks in advance

Sergio

From: Adrian Farrel <[email-masked]>
Sent: Thursday, March 11, 2021 2:42 PM
To: 'Dongjie (Jimmy)' <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: [email-masked]; 'Daniele Ceccarelli' <[email-masked]>; [email-masked]
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

>From my perspective, a VN (ACTN) is a topology carved out of the network and presented to the ACTN consumer, while a VTN (VPN+) is a topology carved out of the network for its own use in delivering enhanced VPNs. That looks pretty much what Jie said: same concept but for different purposes.

FWIW, in draft-king-teas-applicability-actn-slicing we saw ACTN as a tool/mechanism that could be used to realise a network slice or an enhanced VPN. That is, it can build the virtual topology that underpins a network slice.

I think a number of concepts are converging within TEAS. This should be cause for celebration, although it is not always easy to get full convergence.

What we found when writing draft-king-teas-applicability-actn-slicing was that the terminology was not consistent. That, sadly, led us to have to define some of our own terms. I fully expect that as time progresses we will see continued convergence on terminology that will cause a number of us to have to update our drafts.

Cheers,
Adrian

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: 11 March 2021 09:57
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi Sergio,

Hope this helps.

Best regards,
Jie

From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:[email-masked]]
Sent: Wednesday, March 10, 2021 5:18 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Definitions of VTN and Slice Aggregate in the drafts

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: Young Lee <[email-masked]>
Date: Tue, 16 Mar 2021 10:40:18 +0900

Hi all,

I concur with Sergio in this thread. VN has different levels of granularity
such that it can be at the same level as VTN. As Sergio well pointed out,
VN type 2 is a type of Virtual Network "topology" from which operators can
make use of it for its network operation such as mpls, SR, etc.

>From a modeling standpoint, all yang models pertaining to VN (such as VN
yang, TE service mapping, etc.) can be used for VTN contexts as is or can
be augmented for VTN use from existing VN models if need be.

Thanks.
Young

2021년 3월 15일 (월) 오후 9:44, Belotti, Sergio (Nokia - IT/Vimercate) <
[email-masked]>님이 작성:

> Hi Adrian, Jie,
>
>
>
> Thanks for your replies.
>
> Sincerely , while I agree on the fact that VN and VTN are introduced for
> different purpose, nothing prevent to use the “same” concept for different
> context as soon as the concept is covering multiple requirement!
>
> Adrian underlined that ACTN tool/mechanism is able to provide a network
> slice and then an enhanced VPN, and so I do not understand why a VN type 2
> for example should be different to what Jie described as VTN.
>
> Moreover , for VN, exists already a YANG to create a VN and in parallel a
> VN service mapping as well, so question is : is this model able to support
> a VTN as well or, even if for a similar concept , we need to have a
> separate YANG model ?
>
> *From:* Adrian Farrel <[email-masked]>
> *Sent:* Thursday, March 11, 2021 2:42 PM
> *To:* 'Dongjie (Jimmy)' <[email-masked]>; Belotti, Sergio (Nokia -
> IT/Vimercate) <[email-masked]>
> *Cc:* [email-masked]; 'Daniele Ceccarelli' <
> [email-masked]>; [email-masked]
> *Subject:* RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> > As for the VN concept defined in RFC 8453, to me the concept of VN and
> VTN looks similar, while they are introduced for different purposes.
>
>
>
> From my perspective, a VN (ACTN) is a topology carved out of the network
> and presented to the ACTN consumer, while a VTN (VPN+) is a topology carved
> out of the network for its own use in delivering enhanced VPNs. That looks
> define some of our own terms. I fully expect that as time progresses we
> will see continued convergence on terminology that will cause a number of
> us to have to update our drafts.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Teas <[email-masked]> *On Behalf Of *Dongjie (Jimmy)
> *Sent:* 11 March 2021 09:57
> *To:* Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
> *Cc:* [email-masked]; Daniele Ceccarelli <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> Hi Sergio,
>
>
>
> Thanks for your support on the terminology clarification. It is important
> to have consistent understanding about the terminology before we could
> in the layered architecture as described in draft-ietf-teas-enhanced-vpn,
> it is used to organize a subset of the network nodes and links, and
> allocate a set of network resources on these nodes and links to build a
> customized underlay network. Operator can instantiate multiple VTNs to
> carry different types of services, or the traffic of different customers.
> The customers does not necessarily need to be provided with the information
> of VTN.
>
>
>
> *From:* Belotti, Sergio (Nokia - IT/Vimercate) [
> mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, March 10, 2021 5:18 PM
> *To:* Dongjie (Jimmy) <[email-masked]>
> *Cc:* [email-masked]; Daniele Ceccarelli <[email-masked]>;
> [email-masked]
> *Subject:* RE: Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> Hi Jie,
>
> On the other hand I’d like to understand , about “VTN”, what is the
> difference in your VTN concept with respect what already defined in RFC
> 8453 in section 2.1?
>
> A parallel effort with draft-ietf-teas-actn-vn-yang permits to “create”
> VN of the desired type.
>
> So my question is : what in your “new” VTN is different with respect what
> *From:* Teas <[email-masked]> *On Behalf Of *Dongjie (Jimmy)
> *Sent:* Tuesday, March 9, 2021 7:38 PM
> *To:* [email-masked]
> *Subject:* [Teas] Definitions of VTN and Slice Aggregate in the drafts
>
>
>
> Hi all,
>
>
>
> In today’s meeting, some people raised comments about the confusions
> caused by the multiple terms. To help the understanding with the term “VTN”
> and “Slice Aggregate”, I reread the text about their definitions and
> VPN+ is built from a VPN overlay and an underlying Virtual Transport
> Network (VTN) which has a customized network topology and a set of
> dedicated or shared resources in the underlay network.
>
>
>
> A VTN is a virtual underlay network that connects customer edge points.
> The VTN has the capability to deliver the performance characteristics
> required by an enhanced VPN customer and to provide isolation between
> separate VPN+ instances.
>
>
>
>
>
> This document introduces the notion of a slice aggregate which comprises
> of one of more IETF network slice traffic streams. It describes how a slice
> When logical networks representing slice aggregates are realized on top of
> a shared physical network infrastructure, it is important to steer traffic
> on the specific network resources allocated for the slice aggregate.
>
>
>
> Slice aggregate: a collection of packets that match a slice policy
> selection criteria and are given the same forwarding treatment; a slice
> aggregate comprises of one or more IETF network slice traffic streams; the
> mapping of one or more IETF network slices to a slice aggregate is
> maintained by the IETF Network Slice Controller.
>
>
>
>
>
> Slice policy: a policy construct that enables instantiation of mechanisms
> in support of IETF network slice specific control and data plane behaviors
> on select topological elements; the enforcement of a slice policy results
> in the creation of a slice aggregate.
>
>
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 17 Mar 2021 06:27:32 +0000

Hi,

A +1 on what Young and Sergio said.

The definition of VTN says:

   o  A VTN is a virtual underlay network that connects customer edge
      points.  The VTN has the capability to deliver the performance
      characteristics required by an enhanced VPN customer and to
      provide isolation between separate VPN+ instances.

The only thing that is missing in the VN today is the isolation part (which btw seems to be a quite controversial topic not yet fully supported by the WG). However it’s possible to create a VN at different layers using different technologies. If e.g. a VN is created using a specific ODU in an OTN network, that’s absolutely isolated from other traffic.

Could you please help us better understand what is missing in the VN to meet the VTN requirements? If anything is missing I would suggest to augment the VN model rather than creating a completely new one.
A while ago Lou and Pavan suggested to have the VN definition independent from ACTN so that it could have been used outside ACTN context…apparently it was a good move 😊

BR
Daniele

From: Young Lee <[email-masked]>
Sent: den 16 mars 2021 02:40
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: [email-masked]; Dongjie (Jimmy) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>; Young Lee <[email-masked]>
Subject: Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi all,

I concur with Sergio in this thread. VN has different levels of granularity such that it can be at the same level as VTN. As Sergio well pointed out, VN type 2 is a type of Virtual Network "topology" from which operators can make use of it for its network operation such as mpls, SR, etc.

From a modeling standpoint, all yang models pertaining to VN (such as VN yang, TE service mapping, etc.) can be used for VTN contexts as is or can be augmented for VTN use from existing VN models if need be.

Thanks.
Young

2021년 3월 15일 (월) 오후 9:44, Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>님이 작성:
Hi Adrian, Jie,

Thanks for your replies.
Sincerely , while I agree on the fact that VN and VTN are introduced for different purpose, nothing prevent to use the “same” concept for different context as soon as the concept is covering multiple requirement!

Thanks in advance

Sergio

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 11, 2021 2:42 PM
To: 'Dongjie (Jimmy)' <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; 'Daniele Ceccarelli' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,
Clarification on terminology is always a good effort to do  thanks for that.
On the other hand I’d like to understand , about “VTN”, what is the difference in your VTN concept with respect what already defined in RFC 8453 in section 2.1?
In that section there is a description also of the two types of VN , customer can manage.
A parallel effort with draft-ietf-teas-actn-vn-yang permits to “create” VN of the desired type.
So my question is : what in your “new” VTN is different with respect what already defined related to VN to force using another term ?

Thanks
Sergio

Hi all,

In today’s meeting, some people raised comments about the confusions caused by the multiple terms. To help the understanding with the term “VTN” and “Slice Aggregate”, I reread the text about their definitions and descriptions in each draft.

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 17 Mar 2021 09:06:36 +0000

Hi,

As Adrian and I explained in previous mail, VN is an abstracted view of the network provided to a customer, this can be found in the definition of VN in RFC 8453:

  Virtual Network (VN):  A VN is a network provided by a service provider to a customer for the customer to use in any way it wants as though it was a physical network.  There are two views of a VN as follows:

    The VN can be abstracted as a set of edge-to-edge links (a Type 1 VN).

    The VN can also be abstracted as a topology of virtual nodes and virtual links (a Type 2 VN)

Thus the key of VN is “abstraction”. IMO this is different from VTN, which refers to the realization of a virtual underlay network based on operator’s physical network, no abstraction is used in the creation of VTN.

     “Virtual Transport Network (VTN) which has a customized network topology and a set of dedicated or shared resources in the underlay network.

Moreover, in draft-ietf-teas-actn-vn-yang, the instantiation of VN is based on the TE topology model and the TE tunnel model. While VTN is created as a subset of the underlay network topology and network resources, its realization is not bound to the TE tunnels.

Thus in my understanding the VN/VN model and the VTN are used in different layers of the network for different purposes.

Also please note my concern in my previous mail: another consideration was that the term VN is generic (not only defined in RFC 8453), thus could mean different things in different context. Thus we choose to use a dedicated term for the virtual underlay network.

Best regards,
Jie

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Wednesday, March 17, 2021 2:28 PM
To: Young Lee <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: [email-masked]; Dongjie (Jimmy) <[email-masked]>; TEAS WG <[email-masked]>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi,

BR
Daniele

From: Young Lee <[email-masked]<mailto:[email-masked]>>
Sent: den 16 mars 2021 02:40
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Young Lee <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 17 Mar 2021 09:30:29 +0000

Hi Jie,
I do not think Adrian said exactly what you said: he agreed on the fact that the concept is used in different context. This is not in discussion.
BTW the abstraction that you mention is depending of the level customer want to apply, nothing prevent customer to ask for a native topology that nothing is if not the underlay topology that you mention. Section 5 of RFC 8453 explains very the concept.
About what is used to create the required topology is based in what chairs suggested to do, so use the tool already there in TEAS. What do you mean with “network resources” and what would be the model you’d like to use to create your VTN?
“Thus in my understanding the VN/VN model and the VTN are used in different layers of the network for different purposes”
Not clear what you mean here frankly speaking , the underlay or native topology is in the layer that exist depending on the technology is used , there is no difference here based on layers.
Your last concern about the “generality” of the term, is not a valid concern: virtual, abstract, are terms that many time are used in different way, but what I mention as reference is clearly defined, and used to create a specific YANG model, not just words, it is not generic .
Maybe an alignment with your colleagues that worked hard on VN could help the common understanding.

Thanks
Regards, Sergio

From: Dongjie (Jimmy) <[email-masked]>
Sent: Wednesday, March 17, 2021 10:07 AM
To: Daniele Ceccarelli <[email-masked]>; Young Lee <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi,

Best regards,
Jie

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Wednesday, March 17, 2021 2:28 PM
To: Young Lee <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi,

BR
Daniele

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: Daniele Ceccarelli <[email-masked]>
Date: Wed, 17 Mar 2021 09:38:09 +0000

Hi Jie,

No abstraction is not the key of VN, it’s one of the many characteristics associated with it. You can have different levels of abstraction in a VN and in the extreme case 0 abstraction and have all the details of the tunnels and interconnections between them available (you can double check the model).

Regarding the second item:

What is “a subset of the underlay network topology” than can’t be expressed via TE topo + TE tunnel + VN model? Could you please elaborate on what is missing?

Regarding the third item:

Also please note my concern in my previous mail: another consideration was that the term VN is generic (not only defined in RFC 8453), thus could mean different things in different context.

If you prefer you can call it ACTN VN or TEAS VN to provide some context.

All in all I believe these 3 objections are a bit too weak to justify the creation of new terminology and new entities. Augmentation might be needed and is mostly welcome, but I’m against a fork.

BR
Daniele

Sent: den 17 mars 2021 10:07

Hi,

Best regards,
Jie

Hi,

BR
Daniele

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 18 Mar 2021 16:20:48 +0000

Hi Sergio,

I think we may look at different components/layers of the network: you are focusing on the VN model and the related models, while I’m talking about the network states instantiated in the network nodes.

The network view provided by the VN model resides on the network controllers (e.g. PNC, MDSC, CNC in the ACTN architecture). As you mentioned the instantiation of the VN model on network nodes can be based on existing tools (the TE tunnels).

VTN is about the states in the network nodes. Each involved network node allocates and maintains VTN specific topology and/or resource state, which are used to perform VTN-specific packet forwarding. This could be done based on MT or Flex-Algo or similar control plane mechanisms, with SR or MPLS or IPv6 as the data plane, although TE tunnels may also be one option.

Best regards,
Jie

From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:[email-masked]]
Sent: Wednesday, March 17, 2021 5:30 PM
To: Dongjie (Jimmy) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Young Lee <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>; Italo Busi <[email-masked]>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi Jie,

Thanks
Regards, Sergio

From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 17, 2021 10:07 AM
To: Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Young Lee <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi,

Best regards,
Jie

Hi,

BR
Daniele

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 19 Mar 2021 12:38:34 +0000

Hi Jie,

This is the type of augmentation I was referring to. It could be worth considering adding non TE scenarios to ACTN VNs.
VNs could be composed by TE tunnels or non TE constructs/policies.
In the end if a VN member is composed by a TE tunnel, a flex ago o a routing policy doesn’t really make a difference from the VN point of view, simply the path between the end points will not be predetermined and resources won’t be reserved.

BR
Daniele

From: Dongjie (Jimmy) <[email-masked]>
Sent: den 18 mars 2021 17:21
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Daniele Ceccarelli <[email-masked]>; Young Lee <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>; Italo Busi <[email-masked]>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi Sergio,

Best regards,
Jie

From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:[email-masked]]
Sent: Wednesday, March 17, 2021 5:30 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Young Lee <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; TEAS WG <[email-masked]<mailto:[email-masked]>>; Italo Busi <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi Jie,

Thanks
Regards, Sergio

Hi,

Best regards,
Jie

Hi,

BR
Daniele

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Mon, 22 Mar 2021 11:50:12 +0000

Hi Jie,
We already said that the concept is similar but starting from different context. Now it seems to me you’re talking about realization of what you have defined as VTN.
This is your definition “
The definition of VTN says:

It is obvious that also in VN , if you analyzing the realization  you need to consider how the resources in the network are managed and reserved.
One of the point that was raised in the last IETF TEAS presentation regarding VN model, was exactly the need for mapping in the case of SR-policy.
But this is not related to the concept of VN, but to the realization of that.
As correctly pointed by Daniele, this can be part of augmentation we can need to consider  and has to nothing to do with the need for  the definition of another term. already considered in the concept.

Thanks
Regards, Sergio

Sent: Thursday, March 18, 2021 5:21 PM

Hi Sergio,

Best regards,
Jie

Hi Jie,

Thanks
Regards, Sergio

Hi,

Best regards,
Jie

Hi,

BR
Daniele

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 23 Mar 2021 12:46:07 +0000

Hi Daniele,

From your statement, I see that currently VN can be instantiated using TE tunnels, the augmentation with other mechanism is possible and may be discussed further in the WG.

This confirms my understanding that VN as a view on the network controller is decoupled from its realization, the instantiation of a VN in the network is be based on specific technologies, e.g. TE tunnels, etc.

To help understanding, you may consider VTN as one instantiation of VN in the network.

When a VTN is created, the topology and the set of resources are determined, and the states of the VTN topology and resources are maintained on the network nodes involved.

BTW, could you also provide thoughts about other similar terms: slice aggregate and slice policy?

Best regards,
Jie

From: Daniele Ceccarelli [mailto:[email-masked]]
Sent: Friday, March 19, 2021 8:39 PM
To: Dongjie (Jimmy) <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Young Lee <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>; Italo Busi <[email-masked]>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi Jie,

BR
Daniele

To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; Young Lee <[email-masked]<mailto:[email-masked]>>

Hi Sergio,

Best regards,
Jie

Hi Jie,

Thanks
Regards, Sergio

Hi,

Best regards,
Jie

Hi,

BR
Daniele

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 26 Mar 2021 15:06:14 +0000

Hi Jie,

Correct, the VN is decoupled from its realization. Consider that the VN concept is something known just the MDSC/Transport Orchestrator/Hierarchical SDN controller, it’s not something that is implemented on the nodes. The nodes don’t know if a given TE tunnel belongs to a VN or not.

Today the VN is composed by TE tunnels because we focused on TE for ACTN, but the connectivity between a pair of nodes (VN member) can be a SR policy, a flex algo or whatever if the VN is properly augmented. Obviously the TE characteristics would be lost and I don’t think it makes much sense to have network slicing without traffic engineering…but that’s an option as well.

https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-02 provides a good Terminology session (section 1.1) which includes also slice aggregate and slice policy. Please have a look at it.

Slice policy:
      a policy construct that enables instantiation of mechanisms in
      support of IETF network slice specific control and data plane
      behaviors on select topological elements; the enforcement of a
      slice policy results in the creation of a slice aggregate.

   Slice aggregate:
      a collection of packets that match a slice policy selection
      criteria and are given the same forwarding treatment; a slice
      aggregate comprises of one or more IETF network slice traffic
      streams; the mapping of one or more IETF network slices to a slice
      aggregate is maintained by the IETF Network Slice Controller.

The VN could easily be a slice aggregate.
BR
Daniele

From: Dongjie (Jimmy) <[email-masked]>
Sent: den 23 mars 2021 13:46
To: Daniele Ceccarelli <[email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Young Lee <[email-masked]>
Cc: [email-masked]; TEAS WG <[email-masked]>; Italo Busi <[email-masked]>
Subject: RE: [Teas] Definitions of VTN and Slice Aggregate in the drafts

Hi Daniele,

Best regards,
Jie

To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]<mailto:[email-masked]>>; Young Lee <[email-masked]<mailto:[email-masked]>>

Hi Jie,

BR
Daniele

Hi Sergio,

Best regards,
Jie

Hi Jie,

Thanks
Regards, Sergio

Hi,

Best regards,
Jie

Hi,

BR
Daniele

Hi all,

Thanks.
Young

Thanks for your replies.

Thanks in advance

Sergio

Cheers,
Adrian

Hi Sergio,

Hope this helps.

Best regards,
Jie

Hi Jie,

Thanks
Sergio

Hi all,

Best regards,
Jie

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 30 Mar 2021 02:00:32 -0400

All,

>From reading through the thread their are definitely similarities and
differences as well between VTN and VN are which is based on context, but
at the context has overlap, that is where the fun or confusion starts.

VTN termed defined in the context of VPN+ Enhanced VPN where the underlay
resource and degree of isolation underpinning of the VPN+ overlay.

VN termed is an abstraction of the physical network defined in the context
of ACTN made up of TE tunnels but that abstraction could also be SR or Flex
Algo based.

Where these two terms collide is when the VTN underlay underpinning of VPN+
is instantiated and comes to realization or fruition, that realization in
essence becomes an network abstraction or VN, in the ACTN context made up
of TE tunnels but also could be SR or Flex Algo for that network
abstraction, with a slight twist, with the added “resource” and degree of
isolation component added on top of VN.

Kind Regards

Gyan

On Fri, Mar 26, 2021 at 11:06 AM Daniele Ceccarelli <daniele.ceccarelli=
[email-masked]> wrote:

> Hi Jie,
>
>
>
> Correct, the VN is decoupled from its realization. Consider that the VN
> concept is something known just the MDSC/Transport
> Orchestrator/Hierarchical SDN controller, it’s not something that is
> implemented on the nodes. The nodes don’t know if a given TE tunnel belongs
> to a VN or not.
>
>
>
> Today the VN is composed by TE tunnels because we focused on TE for ACTN,
> but the connectivity between a pair of nodes (VN member) can be a SR
> policy, a flex algo or whatever if the VN is properly augmented. Obviously
> the TE characteristics would be lost and I don’t think it makes much sense
> to have network slicing without traffic engineering…but that’s an option as
> well.
>
>
>
> https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-02 provides a
> good Terminology session (section 1.1) which includes also slice aggregate
> and slice policy. Please have a look at it.
>
>
>
> Slice policy:
>
> *From:* Dongjie (Jimmy) <[email-masked]>
> *Sent:* den 23 mars 2021 13:46
> *To:* Daniele Ceccarelli <[email-masked]>; Belotti,
> Sergio (Nokia - IT/Vimercate) <[email-masked]>; Young Lee <
> [email-masked]>
> *Cc:* [email-masked]; TEAS WG <[email-masked]>; Italo Busi <
> [email-masked]>
> From your statement, I see that currently VN can be instantiated using TE
> tunnels, the augmentation with other mechanism is possible and may be
> discussed further in the WG.
>
>
>
> This confirms my understanding that VN as a view on the network controller
> is decoupled from its realization, the instantiation of a VN in the network
> is be based on specific technologies, e.g. TE tunnels, etc.
>
>
>
> When a VTN is created, the topology and the set of resources are
> determined, and the states of the VTN topology and resources are maintained
> on the network nodes involved.
>
>
>
> *From:* Daniele Ceccarelli [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, March 19, 2021 8:39 PM
> *To:* Dongjie (Jimmy) <[email-masked]>; Belotti, Sergio (Nokia -
> IT/Vimercate) <[email-masked]>; Young Lee <[email-masked]
> >
> *Cc:* [email-masked]; TEAS WG <[email-masked]>; Italo Busi <
> [email-masked]>
> This is the type of augmentation I was referring to. It could be worth
> considering adding non TE scenarios to ACTN VNs.
>
> In the end if a VN member is composed by a TE tunnel, a flex ago o a
> routing policy doesn’t really make a difference from the VN point of view,
> simply the path between the end points will not be predetermined and
> resources won’t be reserved.
>
>
>
> BR
> Daniele
>
>
>
> *From:* Dongjie (Jimmy) <[email-masked]>
> *Sent:* den 18 mars 2021 17:21
> *To:* Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>;
> Daniele Ceccarelli <[email-masked]>; Young Lee <
> [email-masked]>
> *Cc:* [email-masked]; TEAS WG <[email-masked]>; Italo Busi <
> [email-masked]>
> I think we may look at different components/layers of the network: you are
> focusing on the VN model and the related models, while I’m talking about
> the network states instantiated in the network nodes.
>
>
>
> The network view provided by the VN model resides on the network
> controllers (e.g. PNC, MDSC, CNC in the ACTN architecture). As you
> mentioned the instantiation of the VN model on network nodes can be based
> on existing tools (the TE tunnels).
>
>
>
> VTN is about the states in the network nodes. Each involved network node
> allocates and maintains VTN specific topology and/or resource state, which
> are used to perform VTN-specific packet forwarding. This could be done
> based on MT or Flex-Algo or similar control plane mechanisms, with SR or
> MPLS or IPv6 as the data plane, although TE tunnels may also be one option.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *Sent:* Wednesday, March 17, 2021 5:30 PM
> *To:* Dongjie (Jimmy) <[email-masked]>; Daniele Ceccarelli <
> [email-masked]>; Young Lee <[email-masked]>
> *Cc:* [email-masked]; TEAS WG <[email-masked]>; Italo Busi <
> [email-masked]>
> I do not think Adrian said exactly what you said: he agreed on the fact
> that the concept is used in different context. This is not in discussion.
>
> BTW the abstraction that you mention is depending of the level customer
> want to apply, nothing prevent customer to ask for a native topology that
> nothing is if not the underlay topology that you mention. Section 5 of RFC
> 8453 explains very the concept.
>
> About what is used to create the required topology is based in what chairs
> suggested to do, so use the tool already there in TEAS. What do you mean
> with “network resources” and what would be the model you’d like to use to
> create your VTN?
>
> “Thus in my understanding the VN/VN model and the VTN are used in
> different layers of the network for different purposes”
>
> Not clear what you mean here frankly speaking , the underlay or native
> topology is in the layer that exist depending on the technology is used ,
> there is no difference here based on layers.
>
> Your last concern about the “generality” of the term, is not a valid
> concern: virtual, abstract, are terms that many time are used in different
> way, but what I mention as reference is clearly defined, and used to create
> a specific YANG model, not just words, it is not generic .
>
> *From:* Dongjie (Jimmy) <[email-masked]>
> *Sent:* Wednesday, March 17, 2021 10:07 AM
> *To:* Daniele Ceccarelli <[email-masked]>; Young Lee <
> [email-masked]>; Belotti, Sergio (Nokia - IT/Vimercate) <
> [email-masked]>
> *Cc:* [email-masked]; TEAS WG <[email-masked]>
> As Adrian and I explained in previous mail, VN is an abstracted view of
> the network provided to a customer, this can be found in the definition of
> VN in RFC 8453:
>
>
>
>   Virtual Network (VN):  A VN is a network provided by a service provider
> to a customer for the customer to use in any way it wants as though it was
> a physical network.  There are two views of a VN as follows:
>
>
>
> Thus the key of VN is “abstraction”. IMO this is different from VTN, which
> refers to the realization of a virtual underlay network based on operator’s
> physical network, no abstraction is used in the creation of VTN.
>
>
>
>      “Virtual Transport Network (VTN) which has a customized network
> topology and a set of dedicated or shared resources in the underlay network.
>
>
>
> Moreover, in draft-ietf-teas-actn-vn-yang, the instantiation of VN is
> based on the TE topology model and the TE tunnel model. While VTN is
> created as a subset of the underlay network topology and network resources,
> its realization is not bound to the TE tunnels.
>
>
>
> Thus in my understanding the VN/VN model and the VTN are used in different
> layers of the network for different purposes.
>
>
>
> Also please note my concern in my previous mail: another consideration was
> that the term VN is generic (not only defined in RFC 8453), thus could mean
> different things in different context. Thus we choose to use a dedicated
> term for the virtual underlay network.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Daniele Ceccarelli [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, March 17, 2021 2:28 PM
> *To:* Young Lee <[email-masked]>; Belotti, Sergio (Nokia -
> *Cc:* [email-masked]; Dongjie (Jimmy) <[email-masked]>; TEAS WG
> <[email-masked]>
> The only thing that is missing in the VN today is the isolation part
> (which btw seems to be a quite controversial topic not yet fully supported
> by the WG). However it’s possible to create a VN at different layers using
> different technologies. If e.g. a VN is created using a specific ODU in an
> OTN network, that’s absolutely isolated from other traffic.
>
>
>
> Could you please help us better understand what is missing in the VN to
> meet the VTN requirements? If anything is missing I would suggest to
> augment the VN model rather than creating a completely new one.
>
> A while ago Lou and Pavan suggested to have the VN definition independent
> from ACTN so that it could have been used outside ACTN context…apparently
> it was a good move 😊
>
>
>
> BR
> Daniele
>
>
>
>
>
> *From:* Young Lee <[email-masked]>
> *Sent:* den 16 mars 2021 02:40
> *Cc:* [email-masked]; Dongjie (Jimmy) <[email-masked]>; Daniele
> Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>;
> Young Lee <[email-masked]>
> I concur with Sergio in this thread. VN has different levels of
> granularity such that it can be at the same level as VTN. As Sergio well
> pointed out, VN type 2 is a type of Virtual Network "topology" from which
> operators can make use of it for its network operation such as mpls, SR,
> etc.
>
>
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*