Re: [Teas] [CCAMP] Decision point on scope of draft-ietf-teas-ietf-network-slices

[Gyan Mishra <[e-mail]>]

Hi Luis

I agree with all of your comments as well from an operators POV.

Nice summarization!

There is a lot of value add to be gained by operators being able to
provision a high tier VPN  w/ SLO called “Enhanced VPN” with finer
granularity with discrete NRP underlay backbone provisioning enhancements
for new service offerings with strict requirements.

Responses In-line

Kind Regards

Gyan
On Thu, Mar 10, 2022 at 6:20 AM LUIS MIGUEL CONTRERAS MURILLO <
[e-mail]> wrote:

> Hi all,
>
>
>
> I think it is important to realize the fact that 5G is not simply a new
> RAN technology, but it is transformational in so many aspects in the way in
> which networks (in a broader sense) are consumed. This also affects to the
> network as defined in IETF terms. This imply so many things as automation,
> SLOs, dynamicity (from ephemeral to long lasting services), SLEs,
> strict(er) service guarantees, etc. Many of these concepts (if not all) are
> not new, which is new is to create a framework that allow to handle all of
> them in the transformational way shown by 5G. But this does not prevent
> that other services different from those based on 5G RAN can benefit of
> these same advances, either for “current” version of those services, or
> “future” variants of them when needing more stringent requirements, in line
> with the evolution of services (XR/VR, metaverse, industrial, etc).
>
>  Gyan>  Lots to gain for operators for being able to take advantage of
> IETF Network Slicing for other value added service offerings beyond 5G
>
> So I would like to remind that there is an ongoing piece of work coming
> from the old times of the Design Team discussions trying to identify use
> cases and requirements to be supported by the IETF Network Slice
> Controller, documented in draft-contreras-teas-slice-nbi. According to this
> discussion and others in the list, I think that a document like that is
> necessary for settling the scope of the work. I would suggest to bring
> there the discussion on use cases and needs to ensure we do not limit or we
> do not skip any need at the time of working on the slicing framework.
>
> Gyan> Agreed. I would be happy to collaborate on the use cases discussions
>
> On the other hand, when we talk about VPN, OTN, etc, we are talking about
> realizations of the IETF Network Slice concept. Certainly, some
> technologies for slice realization will be more suitable to other for
> specific requirements, but not all the slices will have the same set of
> requirements, so depending on the needs, it would be more convenient the
> realization of the slices in one way or another.
>
> Gyan> Agreed
>
> Is it an slice equivalent to VPN with SLOs? Maybe in some cases yes,
> depending on the SLOs needed for the service. Conventional VPNs are created
> at the edge nodes in the network, where certain level of service awareness
> can be retained. However, core backbone nodes have no such service
> awareness, thus not being able to contribute to the distinction of services
> with different needs from different customers. So for services with
> stringent requirements, conventional VPN with SLOs could not be sufficient.
>
> Gyan>  Agreed.  Existing VPN w/ SLO is edge provisioning, however the core
> backbone nodes don’t have the awareness, agreed.  The VPNs w/ SLO can still
> take advantage and degree of isolation slice like characteristics with
> RSVP-TE to VPN mapping onto more isolated paths  or SR-TE micro or macro
> flow steering, however discrete VPN to underlay underpinning resource
> provisioning with network slicing  is still a gap as you point out that
> conventional VPN w/ SLO cannot accommodate.
>
> Regarding OTN, certainly it is a technology that can more easily provide
> certain guarantees, and there are probably mechanisms already there for
> creating a “logical network structures with required characteristics”
> according to framework document . Does it mean that slicing is already
> solved in OTN? Well, there are aspects which are not yet in place (fully or
> partially) when looking at which is stated in the framework document. For
> instance, framework document states (in section 1.1, background)
> “Additionally, the IETF Network Slice customer might ask for some level of
> control of their virtual networks, e.g., to customize the service paths in
> a network slice.” Furthermore, the expectation is that slice customer could
> express slice needs in a terminology agnostic manner, then needing some way
> of translating SLOs and SLEs to specific slice technologies for
> realization. All of this (and probably some other aspects) is part of the
> slice service, even though the realization could (fully or partially)
> leverage on existing capabilities. But in any case there is a need for
> developing new ones, for making the different possible realization
> technologies an alternative for accomplishing the IETF Network Slice
> service in a consistent manner.
>
>  Gyan> Agreed
>
> Finally I would like to comment on the fact of considering different
> technologies for realization. Let me here come back again to the old times
> of the Design Team discussions. While discussing about the usage of the
> term “transport”, at least in my understanding, the conclusion was that the
> work being done here could be of applicability to technologies addressed by
> other WGs (CCAMP, RAW and even DetNet where mentioned in the discussions).
> So I think it was already agreed on the fact that the framework could host
> a number of technologies for slice realization.
>
>  Gyan> Completely Agree
>
> Thanks and apologies for the long mail
>
>
>
> Luis
>
>
>
>
>
> *De:* CCAMP <[e-mail]> *En nombre de *Igor Bryskin
> *Enviado el:* jueves, 10 de marzo de 2022 1:47
> *Para:* [e-mail]; Adrian Farrel <[e-mail]>;
> 'Daniele Ceccarelli' <[e-mail]>; 'TEAS WG' <
> [e-mail]>; 'CCAMP' <[e-mail]>
> *Asunto:* Re: [CCAMP] [Teas] Decision point on scope of
> draft-ietf-teas-ietf-network-slices
>
>
>
> Hi Adrian,
>
>
>
> In response to Igor’s series of emails:
>
>    - If a 5G RAN is supported over an OTN then the concept of an e2e
>    slice requires that there is something that can be called a transport
>    network slice supported by the OTN.
>
> IB:. I think to achieve this it would take basic OTN service delivering
> non-IP client over p2p links, something OTN has been doing for decades.
>
>
>
>    - If the IETF Network Slicing Service YANG module is agnostic of the
>    underlay network, then it should be possible for any network technology to
>    have a go at supporting it.
>
> IB: This includes not just OTN, of course,  but also flexE. microwave,
> OCh, physical fiber, lease line, PW and pretty much anything else that can
> deliver bits from A to B. To paraphrase my favorite Gert's question: what
> is not a transport slice according to the framework?
>
>
>
>    - If a vendor does not want to implement or an operator does not want
>    to support slicing over an OTN, that is a free choice.
>
> IB: of course.
>
>
>
>    - If the concept of slicing an OTN is no different from building a VN
>    or a set of LSPs in that network, why is this whole thing a big deal?
>
> IB: As one Austrian guy said  "sometimes a cigar is just a cigar" and
> should be called cigar, rather than, say, tobaco slice );
>
> Yes, it is not big deal if we stick to VNs, which normally are bottom up
> network building constructs. But it could become a rather big deal if one
> tries to engage OTN directly in the top down netwrk slicing process by, for
> example, creating VNs on the fly.
>
>
>
> Cheers,
>
> Igor
>
>
>
>
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
>
>
> On Wed, Mar 9, 2022 at 12:01 PM, Adrian Farrel
>
> <[e-mail]> wrote:
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
>
> ------------------------------
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is confidential and
> privileged information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*