WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas
Datatracker: https://datatracker.ietf.org/group/teas/about/
13:00-15:00 AEST
https://www.timeanddate.com/worldclock/converter.html?iso=20240319T030000&p1=47
Room: P2 -- https://datatracker.ietf.org/meeting/119/floor-plan?room=p2
Materials: https://datatracker.ietf.org/meeting/119/session/teas
Note taking: https://notes.ietf.org/notes-ietf-119-teas
Onsite tool: https://meetings.conf.meetecho.com/ietf119/?session=32038
Video stream: https://mp3.conf.meetecho.com/ietf119/32038.m3u
Audio stream: https://mp3.conf.meetecho.com/ietf119/32038.m3u
Zuilip https://zulip.ietf.org/#narrow/stream/teas
ICS: https://datatracker.ietf.org/meeting/119/sessions/teas.ics
Recording: http://www.meetecho.com/ietf119/recordings#TEAS
YouTube:
From chat: "YDR" on the document status slides stands for "YANG Doctor
Review"
[Vishnu Pavan Beeram] Documents deemed ready for WGLC -
draft-ietf-teas-5g-ns-ip-mpls,
draft-ietf-teas-actn-pm-telemetry-autonomics, draft-ietf-teas-yang-rsvp,
draft-ietf-teas-sf-aware-topo-model, draft-ietf-teas-yang-l3-te-topo and
draft-ietf-teas-yang-sr-te-topo
No Comments/Questions
Kireeti Kompella: Is the Cross-layer link between the router and the
ROADM referenced in the document connected via grey optics or WDM
optics?
Paolo Volpato: It is grey optics. Everything concerned with non grey
optics is covered in the CCAMP document.
Vishnu Pavan Beeram: Yes, but the CCAMP document is being presented here
too (next slot on the agenda).
Aihua Guo: The confusion regarding grey optics seems to be because of
the illustration shown -- the picture seems to suggest that coherent
pluggables are used. Fixing the picture should address the confusion.
Paolo Volpato: We'll address it.
Vishnu Pavan Beeram: Why do we need a separate document for this? Can
this not be rolled into draft-ietf-teas-actn-poi-applicability? Has this
been separated out just for readability sake?
Paolo Volpato: Yes, primarily for readability sake and also for not
delaying the progress of the other document.
Vishnu Pavan Beeram: Fair enough.
Kireeti Kompella: My question is about setting up the optical connection
and the relevant base optical parameters (e.g., launch power.) Will it
be provisioned from an optical controller or a packet controller? It
should probably be the optical controller. Is this discussed in the
CCAMP document?
Oscar de Gonzalez: We decided for now to leave out any discussion on who
controls the connection in the draft.
Kireeti Kompella: Okay, I will read the draft and come back with more
questions.
[Authors believe that the draft is ready for WGLC]
No questions/comments.
[Discussion regarding options listed for addressing Open Issue: How
many models/drafts?]
Vishnu Pavan Beeram: Which of the options listed does not involve any
changes to the NS service model draft?
Italo Busi: Options 1, 4 and 5
Aihua Guo: Given the mature status of the NS service model (ready for
WGLC), I would prefer going with option 4 (Keep NS Service model as is
and have separate modules for connectivity constraints and topology
intent discussed in this draft)
Italo Busi: We will update the draft with Option 4.
Result: General interest, but not overwhelming
Result: More support than expressed interest. Chairs will discuss;
expect a [WG adoption] poll on the list.
Greg Mirsky: Where is the Composite networks slice defined? Is it
defined by 3gpp?
Jie Dong: No, not by 3gpp. IETF Network Slice Composition is mentioned
in RFC 9543.
Greg Mirsky: It is hard to understand what a composite slice is
especially in the context of 3GPP. There is a need to have a strict
definition and to clarify the scope of the composite slice.
Greg Mirsky: Another question, you mentioned that Network Slice ID in
3GPP may be analyzed by transport network slice; is it the same as NRP
selector? Do we need two of them? This needs to be explained and
clarified. It may be simpler to just do the mapping at the network edge.
Jie Dong: One usage of S-NSSAI is for the 5G to TN slice mapping to
happen at the edge of transport network.
Greg Mirsky: Let's take it to the list discussion.
Adrian Farrel (from chat): We are not the 3gpp.
Tarek Saad: I am little bit confused about the added value of defining
this new construct. NRPs can be provisioned in multiple domains. Why
can't we build on multi-domain NRPs instead of introducing a new
concept.
Jie Dong: There is no conflict between composite slice and multi-domain
NRP, they are on different levels. We can clarify this terminology in
next update.
Greg Mirsky: What is the rationale for separating OAM on arbitrary
parameters -- what do you see as aggressive timers and relax timers?
What is the value for them? Why are there 2 groups of them?
Luis Contreras: The origin of this is coming from a similar exercise
that we did in ORAN alliance. This is just an example. The rationale is
based on the nature of the service. The point of the draft is grouping
of the QIs and the assignment to the queues.
Lou Berger: Can you explain the separation between this document and the
referenced TSVWG document? Why is this also not targeted for tsvwg?
Please take the question to the list.
Tianji Jiang: This looks like it belongs to 3GPP, but 3GPP is not going
to standardize the 5QI to DSCP mapping.
Luis Contreras: This should not be a matter for 3GPP; this document
discusses how to map the 5QIs to the transport network slice.
Result: General interest, but not overwhelming
Result: More support than expressed interest. Chairs will discuss;
expect a poll on the list.
Lou Berger: For those that answered no, please be sure to raise your
objections during WG adoption poll.
Vishnu Pavan Beeram: Typically, the practice is to have RFC4090 based
documents get discussed in the MPLS WG and have TEAS WG notified on the
progress. But since the focal point of discussion in this document is
bandwidth protection and reservation, it seems appropriate to have the
document discussed in TEAS WG. Nevertheless, the TEAS WG chairs will
discuss this further with the MPLS chairs and figure out what is
appropriate.
Greg Mirsky: It seems that you are defining new terminology that is
analogous to Committed Information Rate and Excess Information Rate. Is
that right or is it just my impression?
Rafal: It is your impression; The protected bandwidth is the only new
term that we are using here - it is the volume protected by the bypass;
we are not doing any admission control or rate-limiting here, we
periodically check how much BW is carried by protected LSPs based on the
reservation information and compute a bypass LSP that can accommodate
it.
Greg Mirsky: If you are signaling reservation BW lower than the
protection BW, you are reducing your CIR. Basically, you are allowing
more of your protected traffic to be squeezed out and dropped.
Vishnu Pavan Beeram: What you are saying is true. Most of today's FRR
deployments use zero bandwidth bypass LSPs for local repair and rely on
global repair at the head ends to kick in. But in scaled networks, it
has been observed that the bypass LSPs stay congested for far too long.
All that the authors of the document are doing is recommend a way to
reduce the chances of the bypass LSPs staying congested.
Greg Mirsky: There are infinite number of ways to do it. Are we going to
document all of them?
Rafal Szarecki: Yes, there are different ways to do it. If we do
reservations for bypass it is great, however it is lost capacity, you
have to pay a lot for that capacity.
Greg Mirsky: Please have a look to RFC7412; what will be the value for
the WG to work on this and publish it?
Rafal Szarecki: Qos discussion is orthogonal, if I protect 1Tbps it will
not much help me, it still cause congestion and drops and I have higher
probability for loss.
Tarek Saad: If you have multiple independent PLRs they could end up
sharing same set of links and overloading the bypass paths when in use.
Did you consider reserving protected BW in a different BW pool?
Rafal Szarecki: Yes of course, but that would still come from the
interface bandwidth pool, it will reduce interface capacity. I'm not
sure, but it might require some changes in IGP.
Tarek Saad: DS-TE might help; I will take it offline.
Gyan Mishra: Is this specific to RSVP-TE or does it apply to Segment
Routing as well?
Rafal Szarecki: This is specific to RSVP-TE.