TEAS Notes For IETF 117

Thursday, July 27, 2023

17:00-18:00 PST (00:00 - 01:00 UTC)
Materials: https://datatracker.ietf.org/meeting/117/session/teas
Note taking: https://notes.ietf.org/notes-ietf-117-teas
Meetecho:
https://meetings.conf.meetecho.com/ietf117/?group=teas&short=teas&item=1

Onsite tool:
https://meetings.conf.meetecho.com/onsite117/?group=teas&short=teas&item=1

Audio stream: https://mp3.conf.meetecho.com/ietf117/30479.m3u
Zuilip https://zulip.ietf.org/#narrow/stream/teas
WG ICS: https://datatracker.ietf.org/meeting/117/session/30479.ics

Available post session:

Recording: http://www.meetecho.com/ietf117/recordings#TEAS
YouTube:

Slot# Start Duration Information

01) 17:00 Title: Administrivia & WG Status

Presenter: Chairs

Yi Lin: [Regarding draft-ietf-teas-gmpls-controller-inter-work]
Revision 12 has been uploaded; This revision resolves all the comments
from RtgDir review.

Lou Berger: We'll wait to hear back from the reviewer.

02) 17:10 Title: WG Draft updates

Draft: Many

Presenter: Chairs

Adrian Farrel: [Regarding draft-ietf-teas-applicability-actn-slicing]
With respect to "merging" with
draft-barguil-teas-network-slices-instantation, the authors of both the
drafts discussed and came to the conclusion that it may not be feasible.

Luis Contreras: Updates will be made in
draft-barguil-teas-network-slices-instantation and not in
draft-ietf-teas-applicability-actn-slicing [Discussed further in later
slot].

03) 17:20 Title: Common YANG Data Types for Traffic Engineering

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-rfc8776-update-06

Presenter: Italo Busi

Lou Berger: If you have objections (progress to WGLC), we would like to
hear them now

No objections raised

04) 17:25 Title: A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-33

Presenter: Tarek Saad

Daniele Ceccarelli: Is this document now "really" ready to progress? A
couple of CCAMP documents are blocked by this.

Tarek Saad: Authors believe it is ready. As always, reviews and comments
are welcome.

05) 17:31 10 min Title: A YANG Data Model for requesting path computation

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation-21

Presenter: Italo Busi / Sergio Belotti

No comments

06) 17:50 10 min Title: A YANG Data Model for the IETF Network Slice Service

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slice-nbi-yang-06

Presenter: Reza Rokui

Pavan Beeram: With regards to "custom-topology-ref", are you saying that
this can be used to reference any customized topology including the one
that is discussed in draft-liu-teas-transport-network-slice-yang

Reza Rokui: Yes, in the current version of the model the reference to
the custom topology is for the entire network slice; If there is a need
to reference a specific customized topology for each connectivity
construct within the slice, we can't do that with
draft-ietf-teas-ietf-network-slice-nbi-yang.
draft-liu-teas-transport-network-slice-yang is attempting to fill that
gap.

Aihua Guo: Our view is that if you want the slice service to reference
any specific topology, you should just use
draft-liu-teas-transport-network-slice-yang which augments the base
model specified in draft-ietf-teas-ietf-network-slice-nbi-yang.

Reza Rokui: A point to consider while debating this issue (customized
topology) is to make sure that the progress of the more mature base
model doesn't get impeded by the changes being made to the relatively
less mature models in other documents.

Bo Wu: There was also an earlier comment from Med about the SAP network
topology also being a candidate customized topology. I'm not sure how
the model in draft-ietf-teas-ietf-network-slice-nbi-yang would cover
that. This needs more discussion.

Aihua Guo: My understanding is that the SAP topology is something that
the provider presents to the customer, while what we are discussing is
the topology that the customer is explicitly asking the provider to
provide. In that sense they are different.

Pavan Beeram: Lets move the discussion specific to the comparison of
draft-liu-teas-transport-network-slice-yang with existing topology
models to the later slot. For now focus just on the changes being
proposed in draft-ietf-teas-ietf-network-slice-nbi-yang. Do the authors
want to keep the currently defined custom-topology-ref as is and not
make any further changes?

Reza Rokui: That would depend on whether or not the WG entertains the
proposal being made in draft-liu-teas-transport-network-slice-yang. The
proposal in draft-liu-teas-transport-network-slice-yang is advocating
the removal of custom-topology-ref from the base model.

Dhruv Dhody: There is probably some lack of agreement on this aspect
among the authors themselves. My preference (and presume Bo's as well)
is to keep the custom-topology-ref as is.

Reza Rokui: I'm open to any option.

Italo Busi: It is better to remove the reference from this draft. It is
not clear what specific topology this is referring to -- no clear
semantic. Different implementation may use different semantic and that
would be a nightmare.

Dhruv Dhody: There is precedence in other YANG models for having an
empty container and creating a placeholder for others to come hang items
off it.

Reza Rokui: It should be possible to leave room for both solutions.

Bo Wu: The slice service model currently references ACs and these ACs
can be prebuilt entities. In a similar vein, the topology reference can
reference to something that is prebuilt.

Lou Berger: Comment from Dhruv is pretty good. Leaving an empty
container may be a good way forward.

Pavan Beeram: With regards to qos policies, is there no option to
reference a locally configured policy?

Reza Rokui: If there is anything missing, we'll add it to next rev.

Lou Berger: Please limit the number-of-authors to 5 (or lower).

Adjourn 18:00

Friday, July 28, 2023

09:30-11:30 PST (16:30 - 18:30 UTC)
Materials: https://datatracker.ietf.org/meeting/117/session/teas
Note taking: https://notes.ietf.org/notes-ietf-117-teas
Meetecho:
https://meetings.conf.meetecho.com/ietf117/?group=teas&short=teas&item=2

Audio stream: https://mp3.conf.meetecho.com/ietf117/30478.m3u
Zuilip https://zulip.ietf.org/#narrow/stream/teas
WG ICS: https://datatracker.ietf.org/meeting/117/session/30478.ics

Available post session:

Recording: http://www.meetecho.com/ietf117/recordings#TEAS
YouTube:

Slot# Start Duration Information

-- 09:30 5 min Title: Intro (slides from slot 1)

Presenter: Chairs

07) 09:33 20 min Title: Scalability Considerations for Network Resource Partition

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-nrp-scalability-02

Presenter: Jie Dong

Greg Mirsky: Are you saying that the use of a dedicated identifier for
NRP selector the right approach?

Jie Dong: We are saying that it is the more scalable approach based on
our analysis.

Greg Mirsky: The use of a dedicated identifier will clearly have
deployment challenges. For example, if you are using MNA for carrying
the NRP selector in MPLS networks, we wouldn't be able to support NRPs
(and network slicing) on network elements that are not MNA capable.

Jie Dong: We understand the implications. And that is the reason why
other NRP selector options are also documented.

Greg Mirsky: It is not a question of scalability, it is that of
applicability and deployment. With the option that you are advocating,
some network elements may just not be able to participate in network
slicing.

Jie Dong: This is true with the introduction of any change to the
dataplane.

Greg Mirsky: So, what is the recommendation if you have network elements
that cannot support the dedicate identifier.

Jie Dong: In such scenarios, you use existing fields in the data packet
to carry the NRP selector.

Greg Mirsky: Having multiple options is not ideal. Can't we make a
single recommendation that does not require any new dataplane changes?

Jie Dong: There are scalability challenges with using existing
mechanisms and that is why the dedicated identifier option is also
provider. It is up to the operator to decide what to deploy.

Pavan Beeram: Greg, your point is taken. There are clearly multiple
options for carrying the NRP selector with varying degrees of
scalability. Jie presented the option that provides the best
scalability, but that requires changes to the dataplane. It is up to WG
to decide if we should simply document all the available choices with
their respective scalability considerations and let the operator make an
informed choice.

Tarek Saad: (Question to the WG) There are various NRP specific
documents in other WGs, some of those solution documents are more
scalable than others. Everyone is looking at TEAS to provide guidance on
which of those need to be progressed. How do we go about providing
scalability specific guidance on those documents?

Pavan Beeram: Let me give an account of the lay of the land. We have
protocol extension documents in PCE and IDR that associate a TE
tunnel/policy with the NRP; we have dataplane specific documents for
carrying dedicated identifier for NRP selector; we have documents in LSR
that discuss NRP SIDs and extensions that facilitiate distributed
NRP-aware-TE. The goal of this discussion is to come up (on the list)
with a set of recommended options for the immediate future; there may be
a few that could still continue as experiments, but those wouldn't be
part of the recommended set.

Joel Halpern: I would like to float the idea of moving towards a
solution that does not require any control-plane extensions at all. We
would need to think of what assumptions can be made to get us there.
Folks who are having offline discussion on this topic will look to bring
these assumptions to the list.

Adrian Farrel: Since slicing is a network service function, there will
always be different ways of realizing the service. Some may use existing
solutions, some may need new ways of catering to the service. There
should be a mandate on all the solution documents to have a section that
discusses the scalability implications/considerations for that specific
solution.

Pavan Beeram: Please continue the discussion on the list.

08) 09:57 10 min Title: IETF Network Slice Application in 3GPP 5G End-to-End Network Slice

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-5g-network-slice-application-01

Presenter: Luis M. Contreras

Oscar de Gonzalez: Do you have regular interaction with 3GPP on this
topic?

Luis Contreras: We have regular interaction with folks involved in ORAN.
ORAN liases with 3GPP.

09) 10:05 10 min Title: Instantiation of IETF Network Slices in Service Providers Network

Draft: https://datatracker.ietf.org/doc/draft-barguil-teas-network-slices-instantation-07

Presenter: Luis M. Contreras / Samier Barguil

Pavan Beeram: IMHO, a more appropriate title for this would be
"Applicability of YANG models for IETF Network Slice" or something along
those lines -- similar to the title used for draft-ietf-teas-actn-yang.
The current title is giving the impression that this is yet another
"network slice instantiation mechanism" document.
Please comment on this and also on the merge suggestion (with the ACTN
applicability document) that was made in the previous meeting.

Luis Contreras: Regarding the merge, we did discuss it. We believe that
ACTN applicability only encompasses a subset of the models discussed in
this draft. So, we would like to keep them separate.

Dan King: Speaking as an author of this document and the ACTN
applicability document, there are distinct differences between the two
and merging will not be easy.

Pavan Beeram: Please continue the discussion on the list and see if
there are opportunities to merge with any other documents. If we decide
to proceed with this document without any merge, I would at the very
least like to see the title changed.

10) 10:15 10 min Title: A YANG Data Model for Network Resource Partitions (NRPs)

Draft: https://datatracker.ietf.org/doc/draft-wdbsp-teas-nrp-yang-00

Presenter: Bo Wu

No questions.

Poll (show of hands tool): About one-third of the session participants
participated in the poll; most are supportive of adopting; few
objections (no comments at the mike)

11) 10:22 10 min Title: IETF Network Slice Topology YANG Data Model

Draft: https://datatracker.ietf.org/doc/draft-liu-teas-transport-network-slice-yang-07

Presenter: Aihua Guo

Swamynathan Balasundaram: [Regarding Terminologies] The difference
between customized topology and abstract topology is not clear.

Aihua Guo: Abstract topology is what the provider exposes to the
customer while the customized topology is what the customer is giving to
the provider as an input.

Pavan Beeram: Agree with Swamy. The definitions in this draft are not
aligned with the customized topology definition in RFC8795. Please
revisit.

Oscar de Gonzalez: Maybe, "intended topology" is what you are looking
for.

Oscar de Gonzalez: [Regarding Open issue - customized topology ref in
draft-ietf-teas-ietf-network-slice-nbi-yang] The empty container option
discussed earlier seems to be a good way forward.

Aihua Guo: We can leave the placeholder in there.

Daniele Ceccarelli: Why is ACTN VN not used? That seems to be a perfect
fit.

Aihua Guo: My understanding is that the WG wanted a separate service
model for IETF network slice and not reuse the VN model.

Daniele Ceccarelli: Understand, but for the service request referencing
a topology, reference to the VN seems to fit.

Itali Busi: I see VN model being used when the intent is expressed in
terms of TE metrics while the NS service model being used when the
intent is expressed in terms of SLO/SLE.

Bo Wu: In the network slice service model, we can have multiple
connections with the same set of constraints grouped together in a
connection group.

Reza Rokui: We can have both options -- keep the placeholder in the base
model as is and also have the augmented option in this draft.

12) 10:41 10 min Title: Realization of Composite IETF Network Slices

Draft: https://datatracker.ietf.org/doc/draft-li-teas-composite-network-slices-01

Presenter: Jie Dong

Tarek Saad: Can the content in this draft be merged with the ns-ip-mpls
document?

Jie Dong: We will discuss this offline.

Pavan Beeram: Thanks for merging the two documents! We would like you to
look at options for merging this with a third document - the ns-ip-mpls
document.

13) 10.53 10 min Title: Update on Attachment Circuits Specifications

Draft: https://datatracker.ietf.org/doc/draft-boro-opsawg-teas-common-ac-02

Draft: https://datatracker.ietf.org/doc/draft-boro-opsawg-teas-attachment-circuit-07

Presenter: Mohamed Boucadair / Samier Barguil

Lou Berger: Regarding liaison request from O-RAN, it is to be noted that
no action was requested.

14) 11:02 10 min Title: DC aware TE topology model

Draft: https://datatracker.ietf.org/doc/draft-llc-teas-dc-aware-topo-model-03

Presenter: Luis M. Contreras

Daniele Ceccarelli: How do you foresee the model to be used?

Luis Contreras: The DC will have a gateway and that will be the one
linking the compute capabilities with the transport capabilities. The
information provided in this data model will be taken into account while
instantiation the service.

Daniele Ceccarelli: Are you thinking of a super-controller putting
together a Data Center and the transport world? Never heard of such a
thing.

Luis Contreras: It is something that we need to figure out.

Daniele Ceccarelli: How does this fit with the work being done in CATS?

Luis Contreras: The case of draft-llc-teas-dc-aware-topo-model is more
related to the availability of resources in computing facilities where
no Service Functions have been yet deployed. In fact, the usage of this
model could be precisely to provide TE network topology up to those
facilities with the aim of instantiating Service Functions there. So,
one step before in the overall service lifecycle.

Jeff Tantsura: How dynamic is the data that is being distributed?

Luis Contreras: This is something that needs to be determined. It is
more scalable to lean towards static data.

Jeff Tantsura: It is very difficult to normalize metrics. It may be
useful to look at electrical capacity and things like that as normalized
metrics.

Greg Mirsky: Concur with Jeff.

Poll for interest: Tepid interest; not huge amount of particpation in
the poll

15) 11:15 10 min Title: Some Refinements to RFC8345 (Network Topologies)

Draft: https://datatracker.ietf.org/doc/draft-davis-opsawg-some-refinements-to-rfc8345-00

Presenter: Nigel Davis

No questions.

Adjourn 11:15