WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas
Datatracker: https://datatracker.ietf.org/group/teas/about/
09:30-11:30 America - Pacific Time - Vancouver
https://www.timeanddate.com/worldclock/converter.html?iso=20240725T163000&p1=256
Room: Regency A/B --
https://datatracker.ietf.org/meeting/120/floor-plan?room=regency-a-b
Materials: https://datatracker.ietf.org/meeting/120/session/teas
Note taking: https://notes.ietf.org/notes-ietf-120-teas
Onsite tool: https://meetings.conf.meetecho.com/onsite120/?session=33101
Video stream: https://meetings.conf.meetecho.com/ietf120/?session=33101
Audio stream: https://mp3.conf.meetecho.com/ietf120/33101.m3u
Zuilip: https://zulip.ietf.org/#narrow/stream/teas
ICS: https://datatracker.ietf.org/meeting/120/session/teas.ics
Recording: http://www.meetecho.com/ietf120/recordings#TEAS
YouTube: https://www.youtube.com/watch?v=meSLY9inRfE
Adrian Farrel: Were you asking for specific further action from me? I am
not 100% happy with the way my comments are addressed but we have got
enough consensus to move forward.
Jie Dong: I will review the latest verision and send my comments.
Greg Mirsky: I would like your answer to my comments to be reflected
into the document. It would be useful to have the draft go through
another round of review.
Vishnu Pavan Beeram: About inter-PE transfer plane, I think we can
reword the relevant section without coining a new term.
Lou Berger: If we want to reuse an existing term, Underlay transport
seems reasonable to me
(+1 on chat for this from Daniele Ceccarelli, Dhruv Dhody and Jie Dong)
Krzysztof Szarkowicz: If there is agreement with underlay transport, it
looks ok to me
Mohamed Boucadair (chat): We will move to underlay-transport and move
on.
Ketan Talaulikar: Should we rename the NRP ID to NRP policy ID?
Bo Wu / Vishnu Pavan Beeram: The "name" leaf is for identifying the
policy and the "nrp-id" leaf is for identifying the NRP instantiated by
the application of the policy. The "nrp-id" leaf is meant for use in the
management/control plane.
Joel Halpern (chat): Then, maybe the ID should be called NRP-mgmt-id?
Ketan Talaulikar: I think that selector specific modeling should be
extensible since the data plane specifications are still work in
progress.
Vishnu Pavan Beeram: Acknowledge that this is work in progress; the
model will evolve as the corresponding specifications also evolve; input
is welcome to improve the model.
Jie Dong: I think that with the ACL matching rules, the model is already
quite flexible
Ketan Talaulikar: There is a contradiction in the principles listed
(Slide 6); On one hand you say "routing protocols" do not need to be
involved and on the other hand you say "but when they need to be
involved, use so and so mechanisms"; This contradiction needs to be
discussed further and elaborated upon. We have to be very careful to not
stress the existing protocols at scale. We need an explicit list of
items that are okay to be added and another list of items that are NOT
okay to be added.
Jie Dong: This text is not specific to any routing protocol, it is meant
to be generic. The intention is not to impact the stability of existing
routing protocols. Agree that this needs more discussion.
Greg Mirsky: I concur with Ketan. This isolated information from
existing routing information is a bit vague. More detailed analysis of
IGP, BGP, BGP-LS should be done. Maybe this analysis can be done in
another document and not in this document.
Jie Dong: In this draft we already have a recommendation to provide
scalability considerations in all the drafts which extend the routing
protocols to support NRPs.
Ketan Talaulikar: We need some proposal on what information is needed to
consider the scalability.
Jie Dong: That's why I think that the details should be defined in the
specific protocol extension / solution drafts.
Vishnu Pavan Beeram: Please continue the discussion on the list. We will
try to find avenues to get some more focused discussion on this topic.
Oscar de Gonzalez: If required, at some point we can consider having a
dedicated interim meeting.
Daniele Ceccarelli (on chat): Not debating whether the draft is useful,
but is it something that needs to be published once it has served its
purpose?
Adrian Farrel (on chat): Archiving our work is helpful.
No comments/questions
Vishnu Pavan Beeram: This is a WG adopted document that focues on the
models at the SBI of the NSC, while the next document on the agenda is
focusing on the models applicable at the NBI of the NSC; have you
consider merging these two drafts?
Luis Contreras: It could make sense to do the merge.
[Sergio on TEAS list: Though the scope of the drafts can't be bound to
a specific interface, the discussion on "merge" is still valid]
Poll #1: Is there interest in this topic?
Lou Berger: There is some support and interest in this work
Poll #2: Are there any objections to merging this work with the existing
WG document (NS-controller-models)
Clarification (Poll #3 - Repolling #2): yes means that there is
objection to merge and come to the mic explaining why
Daniel King: The only concern is that the WG document has progressed for
some time and is relatively more mature and the merging effort might
slow down the progress of this work.
Lou Berger: That is a helpful comment. There is some support for merging
the documents (Poll #3). Discussion will continue on the mailing list.
Poll #4: Transport slice yang - Is there interest in the topic?
Lou Berger: Positive but not overwhelming
Poll #5: Is the transport slice yang draft a good starting point for
tackling this topic?
Lou Berger: Not much difference, maybe a few more with no opinion
Dhruv Dhody (chat): Suggest to move these comparisons (VN and NS
relationship) to appendix if this works progresses.
Mohamed Boucadair(chat): They can even be removed once they achieve
their objective: show how the draft complements or is better than the VN
model
Dhruv Dhody(chat):I prefer appendix for a future reader who might have a
questions on why VN type 2 was not used.
Greg Mirsky: Do you think you can sufficiently implement 3GPP network
slices over an existing IP/MPLS without implementing an NRP selector?
Krzysztof Szarkowicz: Yes
Zafar Ali: Map to per hop behavior through DSCP is a good attempt. But
then also you have routing in addition to satisfy your other intent on
top of what QOS or per hop behavior can give you.
Jie Dong: Is the scope of the QoS mapping in this document within a
specific network slice?
Krzysztof Szarkowicz: Scope is clarified in Slide 4.
David Black: The individual draft on TSV WG has expired; I have not seen
any interest to revive this draft; Encourage this draft to be looked at
as a standalone document.
Swamynathan Balasundaram: I think the grouping is a necessary condition
but not sufficient to cater to the requirements.
Krzysztof Szarkowicz: Well, we have still 8 queues, so I need to map all
5QIs into 8 queues
Joel Halpern（chat）：It is not clear to me what it would mean for this to
be a WG Informational draft. Such a status would seem to imply that the
IETF is recommending this approach to 3GPP.
Mohamed Boucadair (chat): 3GPP is not the intended consumer of this
draft; the intended consumers are the operators.
David Black: A liaison to 3GPP will be required if the WG intends to
adopt this. Subir Das and Charles Eckel (on chat) support this view.
Oscar de Gonzalez: Is the work expected to focus on the YANG data model
at the MPI or is it expected to also extend the requirements of the
communication between the NE and the controller?
Paolo Volpato: For sure we will look at the MPI but we can consider also
the device, if needed.
Chaode Yu: I have a draft on resource PM which is applicable to IP and
optical technologies and it could be applicable to this I-D
Paolo Volpato: Yes, you are welcome to send your contribution.
Italo Busi: Regarding the gaps on the device models, for optical
networks most of them are vendor specific so we are not considering it
in the scope of our analysis. For the IP domain, we can follow the same
approach or analyse if there is any gap with standard IP device models.
Oscar de Gonzalez: Yes, we need to focus on the gaps and also on the
communication between the components.