Hi, Snipper, comments inline [JD1].
Yours Irrespectively, John 2. As mentioned several times during the discussion, this underlay construct has both the topology and resource attributes. With the term “resource group”, it is clear that it is a set of network resources, then how about the topology attribute? Is the topology attribute also included in the “resource group”? [JD] There are two separate concepts: 1) Resource Partition - a subset of an underlay network link's buffer/queuing/scheduling resources used to enable the underlay network to have finer grained control of its data plane. 2) Combining these resource partitions into a topology in the underlay network, for which I was using the term 'partitioned underlay network topology'. [TS]: I suggested appending network – i.e. “network resource partition” as more suitable to indicate resources are over an underlay “network” vs. a resource partition over a single link. [Jie] While I understand the intent here is to indicate that the resource partitions are spread over the network, however “network resource partition” could be interpreted as “partition of network resources (e.g. buffer/queue/scheduling resources)”, which does not convey the information we need. Perhaps a more explicit approach is to put network in the end: resource partitioned network (or sub-network), so that it is clear that the resource partitions are spread over the network with a sub-topology. [JD1] How about ‘resource partitioned underlay network’? 3. What is the intended scope of resource group? More specifically, is a point-to-point path or a P2MP path with a set of reserved network resource a resource group? In history, RSVP-TE was used to set up resource reserved point-to-point TE paths and P2MP TE paths. More recently, there is effort in DetNet WG on the mechanisms to set up deterministic data paths. Can these paths be considered as resource groups? Can we further classify them into different P2P resource group, P2MP resource group, or MP2MP resource group? [JD] The connectivity constructs of a given IETF network slice service can be implemented in the underlay network using whatever technologies the provider wishes to use. A given resource partition can support multiple connectivity constructs of any type. [TS]: I agree here. Different connectivity types can be realized over the same network resource partition [Jie] Then my understanding is this underlay construct always provide any-to-any connectivity between the edge nodes, which can be used to deliver services with any connectivity type. Is this correct? [JD1] That’s correct 4. A more subtle question is, what is the relationship between resource group and TE? Is resource group a construct under the TE architecture, or is there some overlap between them? [JD] Resource partitions just provide an enhanced underlay network topology to which a provider can apply TE if they so desire. [TS]: TE can be done over the resources that a network resource partition can offer – for example, to optimally place paths over the remaining resources of network resource partition. [Jie] This may be related to the definition of TE. Is resource partition or reservation one of the components of TE? I hope we can get some answer from 3272bis. We used to define the TE-LSP as something with which we can specify the path and the set of resources reserved along the path. Following this, the underlay construct we are discussing can be used to specify the topology and the set of resources reserved in the topology. If we call the TE-LSP a “TE path”, maybe we can call this underlay construct a “TE network” or “virtual TE network”. Then TE paths can be provisioned in the virtual TE network, just like how the TE paths are provisioned in the physical network. [JD1] I probably wasn’t explaining myself properly The use of resource partitions in the underlay network simply means that there are more resources in the underlay network. The use of the various TE techniques is at the provider’s discretion. I.e., resource partitions and TE are orthogonal. Juniper Business Use Only
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
