Subject: Re: [Teas] TEAS WG Virtual Interim - September 27th - Network Slicing Topics

From: "Wubo (lana)" <[email-masked]>
Date: Tue, 28 Sep 2021 06:54:03 +0000

Hi Sergio,

Thanks for your comments. See inline please. Hope this helps!

Regards,
Bo

发件人: Teas [mailto:[email-masked]] 代表 Belotti, Sergio (Nokia - IT/Vimercate)
发送时间: 2021年9月28日 1:23
收件人: Vishnu Pavan Beeram <[email-masked]>; Wubo (lana) <[email-masked]>
抄送: TEAS WG Chairs <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>
主题: Re: [Teas] TEAS WG Virtual Interim - September 27th - Network Slicing Topics

Hi Bo,
I was in the queue to speak but probably no time and I had not the possibility to talk, Daniele was unfortunately compelled to go away, so I take the opportunity to comment on your slides.

Slide 2: the term “ACTN VN” is wrong and gives people a wrong message: the VN model has been cleaned up following suggestion of chairs, to be used anyway independently of an ACTN architecture .
ACTN is “the primary example of the usage of the VN YANG model” but not exclusive for ACTN. Moreover the drawn on the right is not correct, there is no reason why VN cannot be applicable also to Enhanced VPN.
[Bo] Thank you for clarifying, I was referring to the filename of the VN model.

Slide 3: I think there is a common misunderstanding about this famous “coupling” with TE in the VN model. VN model was started completely decoupled from TE topo, but following suggestion coming from WG active attendee and chairs , the idea was to use as much as possible YANG construct already present in TEAS and in particular in TE topo. But the usage of TEAS topo is way of describe in YANG the VN, but this does not prevent i.e. to have native underline topology as not-TE as already shown by the profile document draft-busi-teas-te-topology-profiles .
[Bo] Thanks for the explanation. My reading is VN model is referring to “ietf-te-topology”.

Slide 4: AP is a logical identifier shared between customer and provider identifying access link in between and “to scope the connectivity requested in the VNS”.  When an access link is added , obviously the connectivity matrix has to change : looking at the picture how P4 can understand if customer desire to send traffic using AP9 e no more AP3 ? In multi-destination service, customer is choosing the list of APs leaving  the network to select which APs to be used as source and destination. If a NSE represent itself a multiple access link, it is not a big deal consider NSE as group of APs, surely not a reason to create a new model !!! Moreover, VN model is based on a public standard information model RFC8453. If you look at the definition of end point in that info model , you can see not much difference with respect what you have described for NSE.
[Bo] The aim of the slide is for comparing  differences between VN AP and NSE definition in draft-ietf-teas-ietf-network-slices. In Adrian’s presentation, there are four options for NSE definition.
My understanding is NSE is more than access link.

Slide 5: same things since the only argument is “tight coupling with TE” and the AP vs. NSE , already commented. By the way the third bullet is wrong, VN is a service intent, and when applied to ACTN, the realization happen at the MPI level not at CMI where VN service is defined.
[Bo] See above please.

Slide 6: as above, also VN is technology agnostic model and intent, btw the SLOs you have defined in your draft does not appear to me particularly technology agnostic but clearly packet oriented (one-way-packet -loss, delay-variation )
[Bo] The definitions are  from  section 4.1.1.1<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-04#section-4.1.1.1>.  of draft-ietf-teas-ietf-network-slices. In our model they are optional.

I think general speaking, there is some important misunderstandings on the VN model and the possible usage of this. I guess we are still on time to talk each other and try to avoid proliferation of models that surely does not help the perception of the good work been done in IETF for slicing.

Regards, Sergio

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Vishnu Pavan Beeram
Sent: Monday, September 27, 2021 2:20 PM
To: TEAS WG <[email-masked]<mailto:[email-masked]>>
Cc: TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] TEAS WG Virtual Interim - September 27th - Network Slicing Topics

WG,

This is a reminder that the virtual interim meeting is today and that it starts in a couple of hours (14:00 UTC).
Meeting URL: https://meetings.conf.meetecho.com/interim/?short=edd4759b-fab1-44f0-8ff3-03bc5b73f907 <https://meetings.conf.meetecho.com/interim/?short=edd4759b-fab1-44f0-8ff3-03bc5b73f907>

Regards,
-Pavan and Lou

On Tue, Sep 21, 2021 at 2:59 PM Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>> wrote:
WG,

As noted earlier, we have a virtual interim meeting scheduled for Monday September 27th at 14:00 UTC.  The focus in this meeting would be on open issues in draft-ietf-teas-ietf-network-slices and IETF Network Slice Service NBI.

The agenda for this session has been posted:
https://datatracker.ietf.org/meeting/interim-2021-teas-01/materials/agenda-interim-2021-teas-01-teas-01-01.txt

Presenters:
Please provide your slides to the chairs/secretary ([email-masked]<mailto:[email-masked]>) by Thursday, September 23rd.

Regards,
Pavan and Lou.

**
Session information:

Time Zone Converter: https://www.timeanddate.com/worldclock/converter.html?iso=20210927T140000&p1=1440&p2=tz_pt&p3=tz_mt&p4=tz_et&p5=tz_bst&p6=tz_cest&p7=tz_cst-china&p8=tz_jst
Session ICS: https://datatracker.ietf.org/meeting/interim-2021-teas-01/sessions/teas.ics <https://datatracker.ietf.org/meeting/interim-2021-teas-01/sessions/teas.ics>
Meeting URL: https://meetings.conf.meetecho.com/interim/?short=edd4759b-fab1-44f0-8ff3-03bc5b73f907 <https://meetings.conf.meetecho.com/interim/?short=edd4759b-fab1-44f0-8ff3-03bc5b73f907>
Jabber: xmpp:[email-masked]?join 
Jabber Logs: http://jabber.ietf.org/logs/teas
Materials: https://datatracker.ietf.org/meeting/interim-2021-teas-01/session/teas <https://datatracker.ietf.org/meeting/interim-2021-teas-01/session/teas>
Note taking: https://notes.ietf.org/notes-ietf-interim-2021-teas-01-teas

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Tue, 28 Sep 2021 08:08:59 +0000

Hi Bo,

Thanks for your reply, but from your answer I’m still convinced there are misunderstanding about VN model.

Regards, Sergio

From: Wubo (lana) <[email-masked]>
Sent: Tuesday, September 28, 2021 8:54 AM
To: Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>; Vishnu Pavan Beeram <[email-masked]>
Cc: TEAS WG Chairs <[email-masked]>; Daniele Ceccarelli <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: [Teas] TEAS WG Virtual Interim - September 27th - Network Slicing Topics

Hi Sergio,

Regards,
Bo

发件人: Teas [mailto:[email-masked]] 代表 Belotti, Sergio (Nokia - IT/Vimercate)
发送时间: 2021年9月28日 1:23
收件人: Vishnu Pavan Beeram <[email-masked]<mailto:[email-masked]>>; Wubo (lana) <[email-masked]<mailto:[email-masked]>>
抄送: TEAS WG Chairs <[email-masked]<mailto:[email-masked]>>; Daniele Ceccarelli <[email-masked]<mailto:[email-masked]>>; TEAS WG <[email-masked]<mailto:[email-masked]>>
主题: Re: [Teas] TEAS WG Virtual Interim - September 27th - Network Slicing Topics

Hi Bo,

Slide 2: the term “ACTN VN” is wrong and gives people a wrong message: the VN model has been cleaned up following suggestion of chairs, to be used anyway independently of an ACTN architecture .
ACTN is “the primary example of the usage of the VN YANG model” but not exclusive for ACTN. Moreover the drawn on the right is not correct, there is no reason why VN cannot be applicable also to Enhanced VPN.
[Bo] Thank you for clarifying, I was referring to the filename of the VN model.
[Belotti, Sergio (Nokia - IT/Vimercate)] I hope now it is clear that VN is more generic model than just an ACTN model.

Slide 3: I think there is a common misunderstanding about this famous “coupling” with TE in the VN model. VN model was started completely decoupled from TE topo, but following suggestion coming from WG active attendee and chairs , the idea was to use as much as possible YANG construct already present in TEAS and in particular in TE topo. But the usage of TEAS topo is way of describe in YANG the VN, but this does not prevent i.e. to have native underline topology as not-TE as already shown by the profile document draft-busi-teas-te-topology-profiles .
[Bo] Thanks for the explanation. My reading is VN model is referring to “ietf-te-topology”.
[Belotti, Sergio (Nokia - IT/Vimercate)] Using teas-topo does not mean to be technology specific and strictly couple with TE as you mention. Yoru presentation is based on that “potential” issue.

Slide 4: AP is a logical identifier shared between customer and provider identifying access link in between and “to scope the connectivity requested in the VNS”.  When an access link is added , obviously the connectivity matrix has to change : looking at the picture how P4 can understand if customer desire to send traffic using AP9 e no more AP3 ? In multi-destination service, customer is choosing the list of APs leaving  the network to select which APs to be used as source and destination. If a NSE represent itself a multiple access link, it is not a big deal consider NSE as group of APs, surely not a reason to create a new model !!! Moreover, VN model is based on a public standard information model RFC8453. If you look at the definition of end point in that info model , you can see not much difference with respect what you have described for NSE.
[Bo] The aim of the slide is for comparing  differences between VN AP and NSE definition in draft-ietf-teas-ietf-network-slices. In Adrian’s presentation, there are four options for NSE definition.
My understanding is NSE is more than access link.
[Belotti, Sergio (Nokia - IT/Vimercate)]The aim is clear but the content does not clarify at all if and what would be the potential differences and above all what would be the scenarios that AP would not be able to  satisfy . Moreover you do not answer my question regarding your example . The definition of NSE is a bit philosophical  I’d like lo understand how it can be applied in real network scenarios.

Slide 5: same things since the only argument is “tight coupling with TE” and the AP vs. NSE , already commented. By the way the third bullet is wrong, VN is a service intent, and when applied to ACTN, the realization happen at the MPI level not at CMI where VN service is defined.
[Bo] See above please.
[Belotti, Sergio (Nokia - IT/Vimercate)] I’ve explained that also third bullet is not correct.

Slide 6: as above, also VN is technology agnostic model and intent, btw the SLOs you have defined in your draft does not appear to me particularly technology agnostic but clearly packet oriented (one-way-packet -loss, delay-variation )
[Bo] The definitions are  from  section 4.1.1.1<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-04#section-4.1.1.1>.  of draft-ietf-teas-ietf-network-slices. In our model they are optional.
[Belotti, Sergio (Nokia - IT/Vimercate)] I’m not argued about definition I’m saying the list of SLO does not appear to me technology agnostic.

Regards, Sergio

WG,

Regards,
-Pavan and Lou

Presenters:

Regards,
Pavan and Lou.

**
Session information: