Re: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

[Igor Bryskin <[e-mail]>]

 Adrian,,  Daniele, Fatai, Aivua and All,
OTN will certainly have a role in network slicing, and I like the idea of having a CCAMP document to this end.This said I have a big issue with the terms "OTN slice" and "OTN slicing".I've raised a few questions. Some of them are not answered yet. Some of them I think need to be answered in broader NS framework context (Adrian's "what's what" discussions ;) )

Let's focus on the following four for now:
- What is the difference between OTN slice and L1VPN?- What is the difference between OTN slice and OTN abstract topology?- How deep into transport layers we have/should/need to go with the network slicing?-  In case of OTN slicing where connectivity types, such as p2mp, mp2p and mp2mp, will come from?

1. We started with: What is the difference between OTN slice and L1VPN? So far I heard: L1VPN is one way to realize OTN slice. Ok, what are other ways? To me OTN slice still looks exactly like L1VPN controlled (as everything else today) via YANG based NBI, rather than SNMP as it used to. What am I missing?
2. More importantly, what is the difference between OTN slice and OTN abstract topology?
In this case the authors seem to see no difference between the two. They use the terms interchangeably and, if one substitutes word "slice" with word "topology" and word "SLO" with "configured link/CM entry attribute", one might very well get verbatim abstracts from ACTN documents. I believe they are confusing slicing with basic resource allocation and abstract topology related operations (thoroughly discussed several years ago in the ACTN context). I don't blame them, the differences are subtle, and AFAIK have not been discussed yet. What is especially confusing is that both Abstract Topology service and Network Slice service may refer to the same abstract topology, but for different purposes and with different benefits for the client.
I could be wrong here, but after all the discussions we have had in the context of NS, I've come to see a big difference between the Abstract Topology service and NS service. The main role of the former is to allocate resources for and convey to the client characteristics of a logical network (either configured by the client or internally generated by the server) as snapshots in time - at the time of the topology presentation following with notifications about changes. This allows for the client to make proper TE decisions, like accurate path computation.
I think NS service includes Abstract Topology service but goes way beyond that. One important role of the NS service is to *sustain* logical network characters (SLIs) over the service lifetime constantly bending them towards committed SLOs under conditions of some adversity, such as congestion, misbehavior of other slices, etc. This allows for the client to utilize logical network as a stable, reliable, predictable and independent physical network. Importantly, while this role is imperative and challenging in a messy layer network with shared continuous media (like IP), in the well organized  OTN l, where network resources are split neatly and naturally into tokens/units inherently independent from each other, said NS service role amounts to very little (if anything at all). 

Another important role of NS service is to provide various connectivity constructs, some of which - p2mp, mp2p, etc.-  cannot be modeled as topological elements. Again, while meaningful in IP, in OTN with its connection-oriented connectivity effectively limited to p2p, this NS service role also amounts to nothing. Therefore, I believe that, while Abstract Topology service is useful in all layers, NS service could be limited to packet switching layers, and the usual pattern -here is layer independent stuff and here are layer specific augmentations- should be broken for NS.
3. How deep we have to go with network slicing?
We all understand and agree that NS is needed in IP (and for very good reasons). But should/could we stop at IP or should we slice into transport layers? If the latter, why stop at OTN? Perhaps we should slice OCh and other layers all the way to the fibers (and surely find a way to slice fibers as well;))? And what about networks without OTN layer? with the network slicing will be different on such networks?My answer: not only we need to build network slicing top to bottom (as Adrian and Gyan say), we should stop slicing at IP (for the reasons described above in 2) and have lower layers support the IP slices ideally in exactly same way as all their other clients, that is, doing nothing specific for IP slices. Surely, this would keep inter-layer relationships much simple.
4. Where p2mp, mp2p, mp2mp connectivity will come from?
NS framework requires various connectivity types to be provided/supported by NS service. Some of them for all practical purposes could be achieved only in Ia connectionless packet-switching layer, such as IP (its inherent connectionless nature gives rise to most efficient realization of such connectivity types). This IMHO is another reason why we should limit network slicing to IP layer. Otherwise, where the complex connectivity types will come from?

My conclusion is this. Network slicing could and should be limited to IP layer. The underlying transport should support IP slices, but not perform slicing itself. The tools available to transport layers - topology, tunnel, path computation, VN, etc. models/NBIs should be sufficient for this purpose. A document describing this would be useful.
Cheers,Igor

    On Friday, January 21, 2022, 03:26:15 AM EST, Gyan Mishra <[e-mail]> wrote:  
 
 
Hi Adrian 
I agree with all your comments related to this draft especially the complexity with this approach as compared to ACTN architecture.  One critical  point you make is that the slice service should be independent of underlay technology.  As OTN is a component of the underlay it goes against the agnostic slice approach taken with IETF Network Slice.  
Others have mentioned the same related to underlay technology slice added complexity and does that mean a different  slice Yang model for each L1 Technology “Bottoms Up” approach. 😁
Comments in-line 
Kind Regards
Gyan
On Thu, Jan 13, 2022 at 12:20 PM Adrian Farrel <[e-mail]> wrote:


Hi Fatai, Daniele,

 

I think that CCAMP should work on YANG models for slicing OTN networks. I think that this draft forms a starting point and should be adopted, but like Igor, “I have questions”.

 Gyan>  I support WG adoption and I think all the comments mentioned can be addressed.

So, my support for adoption is heavily conditional on the authors not believing that the approach used in the draft is fixed. (This is normal, but it is worth highlighting in view of my thoughts, below).

  

I am particularly interested to look at harmonising this work with draft-ietf-teas-applicability-actn-slicing and draft-ietf-teas-ietf-network-slice-nbi-yang (I appreciate the work the authors have done to synchronise with draft-ietf-teas-ietf-network-slices). 

     Gyan> Agreed


I think one question here is whether the “slice request” interface shouldn’t actually be built on draft-ietf-teas-ietf-network-slice-nbi-yang (i.e. top down, not bottom up as currently). 

    Gyan> Agreed.  


The point being that “The definition of an IETF Network Slice Service is independent of the connectivity and technologies used in the underlay network” [draft-ietf-teas-ietf-network-slices] meaning that the NBI in this model could be a technology-specific augmentation of draft-ietf-teas-ietf-network-slice-nbi-yang.



    Gyan> Agreed 

Another question is why there is the need to introduce the complexity of interfaces and controllers shown in Figure 2, when Figure 1 of draft-ietf-teas-applicability-actn-slicing considers a more simple mapping between the slicing and ACTN architectures. That is, why does the CMI appear as different from the OTN-SC NBI and the NSC NBI?

   Gyan> Completely Agree.  ACTN mapping is a much simpler mapping.



We might also debate the meaning of “E2E Slice Controller” since this term is not mentioned anywhere except in Figure 2 and only appears once in draft-ietf-teas-ietf-network-slices (in Figure 2) that appears to have escaped being cleaned up.

 

But, I think these are questions that can be easily resolved in discussions within the WG, so adoption should be safe.

 Gyan> Agreed 

Best,

Adrian

 

PS. At some stage the AD is going to ask, “Please find a way to reduce the front page authors to 5 or fewer.” Experience suggests that it is easier to do this sooner rather than later, and it is better if the authors resolve that rather than requiring the chairs to force the point.

 

From: CCAMP <[e-mail]> On Behalf Of Fatai Zhang


Sent: 12 January 2022 02:24
To: CCAMP <[e-mail]>
Subject: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

 

Hi all,

 

All the IPR declarations regarding draft-zheng-ccamp-yang-otn-slicing-03 have been collected, this starts the polling for WG adoption.

 

The poll will last 2 weeks and will end on Wednesday January 26th.

 

Please send email to the list indicating "yes/support" or "no/do not support" and a motivation for your reply, mandatory for the "not support" and nice to have for the "support".

 

 

Thanks,

 

Fatai & Daniele

 

 

 
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp

-- 




Gyan Mishra

Network Solutions Architect 

Email [e-mail]


M 301 502-1347



_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp