Meeting Notes - TEAS WG Session - IETF 123

WG ICS: https://datatracker.ietf.org/meeting/123/session/34245.ics
Datatracker: https://datatracker.ietf.org/group/teas/about/

Wednesday, July 23, 2025

11:30-13:00 Europe - Madrid Time
https://www.timeanddate.com/worldclock/converter.html?iso=20250723T093000&p1=141

Room: El Prado --
https://datatracker.ietf.org/meeting/123/floor-plan?room=el-prado

Materials: https://datatracker.ietf.org/meeting/123/session/teas
Note taking: https://notes.ietf.org/notes-ietf-123-teas
Onsite tool: https://meetings.conf.meetecho.com/onsite123/?session=34245

Video stream: https://meetings.conf.meetecho.com/ietf123/?session=34245

Audio stream: https://mp3.conf.meetecho.com/ietf123/34245.m3u
Zuilip: https://zulip.ietf.org/#narrow/stream/teas

Post session materials:

Recording:
YouTube:

Slot#) Start | Duration | Information

01) 11:30 | 15 min | Title: Administrivia & WG Status

Presenter: Chairs

02) 11:45 | 10 min | Title: WG Draft updates

Draft: WG Drafts (not on agenda)

Presenter: Chairs

03) 11:55 | 10 min | Title: TEAS and ONIONS

Draft (ONIONS Charter): https://github.com/boucadair/WG-Charters/blob/main/onions.md

Presenter: Joe Clarke

Kireeti: I am very interested in L2SM/L2NM/L3SM/L3NM and we have done
some implementations with YAML to YAML or XML to XML mappings where a
customer service is mapped into the network, so I have no problem with
that. We have some ideas for enhancements to L2SM/L2NM, should that work
go to ONIONS or stay in OPSAWG?

Joe: Now ONIONS is not yet a chartered WG, so it would probably go to
OPSAWG. If ONIONS is chartered, one of the milestones of the draft
charter is a next revision (a bis) of the network models and service
models and that would definitely comes to ONIONS.

Kireeti: Ok. So I need to join the mailing list.

Joe: Yes. There is already a non-WG mailing list (onions@ietf.org)

Zafar: Can you clarify the scope of the open API? What do you plan to
cover?

Joe: the draft charter text uses the words "open space API" which was
confused with Swagger OpenAPI during the side meeting. People have done
conversion of YANG data models to Swagger and they pointed out that you
get a lot of endpoints but not the same value as with working with YANG
because you need to know the procedure (what to set first). The thinking
was that maybe Swagger OpenAPI is not the right API to choose and maybe
we need something which looks more language centric (e.g., something
more "Pythonic" for Python language) with classes and methods such that
you feel you are in that language. We felt that it is more up to the WG
to define which is the right API to use, so we are leaving with just an
"open API" and figure out what it is from who are contributing to the
work.

Lou: what is the timeline?

Joe: Dhruv and I have to adjust the charter text based on the feedbacks
from the side meeting. We are planning to do that by this week and
propose the updated draft charter to the mailing list. We can have the
WG chartered by the end of IETF and have the WG formed before IETF 124

Lou: why no BoF?

Joe: I do not know. If feels like the NEMOPS gave some sort of mandate
or some impetus to take actions

Lou: ADs can run thing the way they want but it seems to me that this
discussion is a little premature. This is a comment to the ADs: I would
like to have a public discussion about this before the WG is chartered,
for example what is the role? what are you really trying to achieve?
does it make sense from other WG context? We need some open discussion
beyond a non-WG mailing list. I appreciate running fast but we missed an
opportunity at this meeting to have a BoF.

I am raising a process point here and I think we are premature.

Jim Guichard: I haResponsible AD for TEAS WG has not agree on moving any
TEAS WG document elsewhere

Med (OPS AD): We have feedback form many people interested in the work.
We have reached out to all the WGs that may be impacted (we have reached
out TEAS WG in May). If you have an issue, please come back to us to
discuss.

Luis: In Telefonica we are very interested on service abstraction. We
need to look at how our service models are going to be consumed

Haomian: I wold suggest to describe how you are planning to enhance the
current documents and get technical experts joining the work

04) 12:05 | 10 min | Title: IETF Network Slice Topology YANG Data Model

Draft: https://datatracker.ietf.org/doc/draft-ietf-teas-network-slice-topology-yang/01/

Presenter: Italo Busi

No questions.

05) 12:15 | 10 min | Title: 5QI to DiffServ DSCP Mapping Example for Enforcement of 5G End-to-End Network Slice QoS

Draft: https://datatracker.ietf.org/doc/draft-cbs-teas-5qi-to-dscp-mapping/04/

Presenter: Luis Contreras

Oscar: is the scope of the draft limited to mapping only to DSCP values
or includes also mapping to SLO?

Luis: just to DSP. The objective is to aggregate or group per
characteristics the different FQI as in slide 7 and map them to
different queues so basically it will be the DSCP

Oscar: Who do you think is the intended reader of the draft and apply
this mapping? Within or outside IETF?

Luis: Mainly IETF. We need some guidance on how to proceed with this
variety of flows that we need to manage. We are not introducing any
change in 3GPP so for 3GPP this should be something transparent.

Adrian: I am struggling a bit with the scope and the purpose of this
document and your answer to Oscar. You used the word "guidance" but the
text at the moment says "illustrative examples".
I am struggling because this is definitely useful work, it establishes
that it is possible to map but it also says that anyone can map anyway
they want and here are just some ways it can be done.
Why do we need to go any further than having made that having
established that fact?
Why do we need to adopt this work and become an RFC?

Luis: We think that having a kind of methodology could guide the
operators to handle the diversity of flows.
Somehow there could be always a way of describing the way different
operators handle the traffic internally. It is mainly offering a
methodology to deal with the other parties on the mobile side.
In the particular case of Telefonica, for instance, we have different
operations across the world and this would help us to have a common
guidance across all our networks.

Adrian: Maybe the question is whether there is a need for
interoperability.

Luis: Interoperability could be a target.
There was an analysis in the past from NGMN on how the different
operators can do the mapping. It could be a problem having the same kind
of mapping in each operator, but the idea is how groups could be common
all of them.
Basically, interoperate in terms of semantic on what we expect for each
group, rather than particular DSCP marking. Probably the DSCP value
could be different
how we would threat the traffic even if the DSCP code is different but
the semantic of how to treat the traffic could be common.

Boris: I think it could be an Informational RFC providing guidance or
reference to operators. So definitely it goes beyond just IETF people.
It could be helpful to other operators abroad with all needed
clarifications, like Adrian said.

Kireeti (on Zulip): “Best suggested practice”

Pavan: When this draft was presented last time in TEAS WG, it was IETF
120, there were some vocal comments from TSVWG people expressing some
reservations on this work. You did present last time to TSVWG as well.
There were also comments requesting getting input from 3GPP and from
operators community.
So we do not have an answer to you yet on what is the home WG for this
draft. We will have some conversations and the decide on what would be a
suitable home.

Luis: we will insist on trying to collect more comments from TSVWG so we
can have all the fronts covered.

Adrian (on Zulip): Go straight to adoption.
Joel shouldn't beat himself wrt KARP. 6518 is pretty clear on the need
for key agility. It's just that no one did the follow-up work (until
now)

Mark Grayson (on Zulip): How does this compare with GSMA IR.34 5QI to
DSCP mapping?

Luis (on Zulip): thanks for the question. We were looking recently to
IR.34 as well. IR.34 describe an explicit mapping of DSCP values to
classes with specific PHB values. Here the mapping of the QCIs is not to
specified values, there is freedom in that respect. Moreover we
concentrate on the case of slicing, while IR.34 is more general and
focused on interconnection, no access. If would like to reconcile this
approach with the one in IR.34 would require a triple mapping among 5QI
- DSCP - IPX... quite complex. But certainly, as said, is something we
are looking at as well, so a relation to it could be made evident as one
of the next steps of the draft.

06) 12:25 | 15 min | Title: RSVP Cryptographic Authentication

Drafts: https://datatracker.ietf.org/doc/draft-atkinson-teas-rsvp-auth-v2/02/ and https://datatracker.ietf.org/doc/draft-atkinson-teas-rsvp-hmac-sha2/00/

Presenter: Joel Halpern

Pavan: Tony presented the first draft at IETF 121 and we did a poll then
showing interest for adoption. Based on that, we have added it to the
adoption queue: you can see an adoption call in the next few weeks.
The second document is a companion document and it makes sense to
progress it along with the first document.
In IETF 121 there were suggestions to keep TSVWG and SAAG WGs informed
as well, so we will look to do that.

Reshad (on Zulip): OOC is there a "registry" for those Apads?

Joel (on Zulip): No, there is no registry for the Apads.

07) 12:40 | 15 min | Title: Multipath Traffic Engineering

Drafts: https://datatracker.ietf.org/doc/draft-kompella-teas-mpte/01/, https://datatracker.ietf.org/doc/draft-kbr-teas-mptersvp/01/ and https://datatracker.ietf.org/doc/draft-beeram-teas-yang-mpted/00/

Presenter: Kireeti Kompella

Lou: Have you thought about using this for protection in addition to
just do load balancing?

Kireeti: Yes. When there are multiple next hops (e.g., three), if one of
them goes down it is possible to change the balance across all the
remaining next hops.
SRLG should also be taken into account: if all the next hops have the
same SRLG, protection is needed.
So there are cases where there is a single next hop and protection is
needed. If there are multiple next hops with different (or unknown)
SRLGs, protection might not be needed.
So very good point and we will expand on that in the next updates.

Lou: I think you are talking about load balancing plus protection, which
you have talked about earlier. I am talking just about protection.
At each junction in the DAG you choose one output.
The problem is when the failure is multiple junctions away, you might
take the wrong choice.

Kireeti: Ok, I have thought a little bit about that, especially when you
have a sequence that is single hops all the way to that point. One of
the option is to use a notification. Most notifications right now are
from junctions to source but we may have a notification from junctions
to prior junction.

Pavan: in slide 12, a junction to junction (J2J) message is defined
where a sequence of junctions with one next hop can be used.
For example, in slide 13, if the link between R6 and R8 breaks, R4 needs
to be informed that the junction is down otherwise it will keep sending
traffic to R6 next hop.
So where the entire junction goes down, there is a J2J notification that
is sent to the immediate upstream junction which would immediately
invalidate the next hop.

Lou: I assume it works for any number of links, just the last link,
right?

Pavan: Yes

Lou: That would definitely cover it. I think that this particular use
case is very applicable to the architecture which is now finalizing the
RFC publication at Detnet WG. There is language there talking about DAG,
protection and making decisions at each (not called junction there) but
this aligns very well if you allow for that use case.
I think that there would be interest in Detnet WG for using this
mechanism.

Lou: Have you though about not notifying for all egresses or all paths,
just to reduce the number of messaging?

Kireeti: We went back and forth on that. We ended up saying to send
notifications so that the head end has a better picture of everything.
The amount of state and the amount of messaging right now is pretty low
but the notifications themselves almost doubled so it is something to
think about.
Implementations will guide us. We have several ideas: one is to do it
periodically.

Lou: there is a lot of opportunity for reducing or optimizing
notifications. You need to get the first one when you have a full
end-to-end path. After that, it gets less clear.

Kireeti: Yes.
On thing I should have mentioned is that now that you have a path with a
DAG, is no longer a binary up or down, so there is a notion of degraded
where not everything comes up. In this case, maybe you do not have fully
capacity but you have a functioning DAG.

Lou: I need to understand how the whole bandwidth management works but I
do not see how it could work without a log of over-booking.

Adrian (on Zulip): Anyone remember whether RSVP-TE segment protection
can do this already?

Pavan (on Zulip): Carrying junction state for every junction in the same
Path (which is how SEROs are signaled) is cumbersome when you are
provisioning a large number of junctions

Adrian (on Zulip): It is, of course, a trade between the number of
messages and the amount carried in one message

Oscar/Pavan: we are running out of time so we are cutting the queue
here. Please take your comments to the list

Adjourn 13:02