Adrian Farrel
Luis M. Contreras
Session:
Tuesday, November 9 2021
14:30-15:30 Session II (UTC) and 16:00-18:00 Session III (UTC)
Time Zone Converter: https://www.timeanddate.com/worldclock/converter.html?iso=20211109T143000&p1=1440
Materials: https://datatracker.ietf.org/meeting/112/session/teas
Note taking: https://codimd.ietf.org/notes-ietf-112-teas
Meetecho: https://meetings.conf.meetecho.com/ietf112/?group=teas&short=&item=1
Audio stream: http://mp3.conf.meetecho.com/ietf112/teas/1.m3u
Jabber: xmpp:teas@jabber.ietf.org?join
WG ICS: https://datatracker.ietf.org/meeting/upcoming.ics?filters=teas
Session ICS: https://datatracker.ietf.org/meeting/112/sessions/teas.ics
Available post session:
Recording: http://www.meetecho.com/ietf112/recordings#TEAS
Jabber log http://jabber.ietf.org/logs/teas
YouTube: https://www.youtube.com/watch?v=K0fqnpBD3yc, https://www.youtube.com/watch?v=917s3IVc3OU
Presenter: Chairs
Welcome to Luis as the new WG Secretary
Presenter: Chairs
Adrian Farrel : With regards to 3272bis, a new revision has been posted as keepalive and also to address one of Med’s comments
Lou Berger: With regards to YANG-TE, one of the authors’ mail is bouncing. Ask authors to get updated email from that author.
A YANG Data Model for VN Operation
YANG models for VN/TE Performance Monitoring Telemetry and Scaling Intent Autonomics
Traffic Engineering (TE) and Service Mapping YANG Model
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-13
https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-pm-telemetry-autonomics-07
https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-09
Presenter: Dhruv Dhody
VN YANG
Lou Berger: Not clear what the CoS change was for
Pavan Beeram: You are just using the DiffServ class type?
Lou Berger: Just add some description of how it is to be used
Dhruv Dhody: Will add text from original request (from Kenichi)
Pavan Beeram: Use of empty container for future proof. Need review on whether that is right
Jeff Haas (in chat) : An empty container as a “well known mount point” is a nice idea.
Kiran Makhijani (in chat) : Question on ‘empty container’: doesn’t yang model allow augmentations inherently, does it really add value to have a place holder for ‘empty thing’?
Dhruv Dhody (in chat): as Jeff said it is a good practice sometimes to guide the exact point where augmentation is intended
Kiran Makhijani (in chat): but that could apply to any data-structure or container used in the models
Qin Wu (in chat): yes, it is a good pratice, see RFC8345, RFC8346 for examples
Kiran Makhijani (in chat): I find ‘Type’ problematic wrt Connectivity matrix. but can not come up with alternate term.
PM Telemetry
[on slide] Should OPSAWG review be initiated by authors or chairs?
Pavan Beeram : “We can do that” at the same time as YANG Dr. Review
Lou Berger : YANG Dr review involves also AD from OPS area, so they will chime in if needed
Tarek Saad : Does this cover the service telemetry or is this just for the transport
Dhruv : Just the transport. Network slicing is not covered in this.
TE service mapping
Lou Berger : Document is pretty much mature. If we add slicing, it can slow down the process for progressing the document. Better to keep them apart.
Lou Berger : There are two new paragraphs describing what is out of scope. Generally RFCs are silent on out of scope topics, should we keep them?
Dhruv Dhody : Question to be posted to the group; will let the group decide
Adrian Farrel : The intention was to make evident what is left out of the scope, that way future readers are informed (and not question about those aspects).
Lou Berger : Probably making evident what is out of scope is opening questions. As chair – generally best to not make statments of what is out of scope (best to be silent). As contributor – I’d prefer both paragraphs are dropped. We can discuss on the list after you consult with your coauthors.
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05
Presenter: Adrian Farrel
//insert slot discussion notes here
Tarek Saad : Question on P2P. We talk about connectivity matrix and about connections. Can we associate serveral connections to a single matrix?
Adrian Farrel : I don’t see it helpful to talk about connections on connectivity matrix.
Tarek Saad: For two endpoints with two connections, should I propose a connectivity matrix with two connections, or propose two P2P connectivity matrices?
Adrian Farrel : Need to fix definition in P2MP case.
Tarek Saad : In TE topology module we used connectivity matrix, with more than one entry.
Adrian Farrel : Let’s check terminology. Alignment would be best.
Toerless Eckert : Really only have two connectity types: P2P and P2MP, everything else is just a combination. No need for a long flat list of connectivity. Probably good to add others (hub and spoke, etc).
Adrian Farrel : Hub and spoke is realization in the network, we’re talking from the service perspective. The user does not have control on what the network is doing.
Toerless Eckert : My example talks on customer side.
Adrian Farrel : We can revisit this.
Toerless Eckert : We can assume fundamental P2P connectivity and base the rest on this, without the need of listing some schemas and not others.
Srihari Sangli : As of now, receiver CE’s SLO only can be derived indirectly. Is it possible to get them directly.
Adrian Farrel : I would like to know cases where this is needed.
Lou Berger: How many external services are to be exposed (bidi P2P, P2MP). Bidirectional is important, past IETF discussions suggest we keep it in. Not clear what A2A means.
Luis Contreras: A case for requiring explicit receiver SLOs is the consideration of unicast or multicast
Adrian Farrel : You can get whatever you want from A2A
Wim Henderickx: Try to model as much as possible based on a collection of basic P2P connections. For instance for multi-homing.
Adrian Farrel: Need to think on multi-homing.
Luay Jalil : Not clear to me how we define the CE.
Adrian Farrel : Refer to endpoint discussion coming up later. I am not comfortable with “CE”, as the service endpoint might be a service function in the network, or might be placed in a PE.
Continuing with the previous presentation
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-05
Tarek Saad: Question on connectivity matrix ID. Need to group connectivity matrices to match specific filter criteria. E.g., P2P and want to associate a class of service to them.
Adrian Farrel: We are moving from how the slice is requested from the customer to how such slice is realized. Clear to me that some matrices could be aggregated.
Reza Rokui: it makes sense to group the matrices as unicast or mutlicast. Could be based on P2P and P2MP. Another comment, about connectivity matrices. Maybe good idea to clearly state what we mean by connectivity matrix.
Adrian Farrel: Having aligment with the NBI YANG mdoel is also fundamental
Gyan Mishra : Use P2P as basic connection from where to build up the rest.
Greg Mirsky : P2MP is not only restricted to multicast, unicast can also be delivered.
Adrian farrel : P2MP was initially intended to reflect multicast. We need to bash it out.
Jeff Tantsura : Important to define where is the boundary in P2MP if the traffic is replicated. It is not necessarily only traffic that is defined in the connectivity matrix. For instance, assuming some traffic quota, adding a new receiver in this way could imply that the quota is exceeded.
[on NBI/SBI slide]
Luay Jalil : Question about the placement of Network Controller, IETF NEtwork Slice Controller and Orchestrator on top. Do they sit on the customer side?
Adrian Farrel: Orchestrator is on customer side.
Luay Jalil : Can be the IETF NSC part of the network controller?.
Adrian Farrel : Yes, it is implementation based
Kireeti Kompella : Classifying the models as intent and implementation model can be helpful. We need more uniform terminology across all service models.
Adrian Farrel : There was discussion on the use of “customer”. Customer is the entity making requests of the service. Need to see if intent is a robust definition of the slice request.
Kiran Makhijani : Question on the downward arrows for the configuration; Is this intended?
Adrian Farrel : No, it is inconsistent documentation.
Lou Berger : It would be useful to have alignment with rfc8309, esp. Orchestrator vs controller. Nice to be aligned with an RFC. But if terminology creates confusion, better not to follow the RFC.
Adrian Farrel : Noted.
Luay Jalil : There can be infrastructure endpoints (e.g. DU, CU). Endpoints could be not only at the customer side. Regarding QoS, QoS can exist without slicing.
Adrian Farrel : Noted. Also point valid for customer to cloud.
[on Technology-agnostic issue slide]
Luay Jalil : Agree with the proposal.
Kireeti Kompella : This is intent vs implementation. Intent is the what. The agnosticism is with respect to how the slice is implemented.
Presenter: Adrian Farrel
Draft: https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slice-nbi-yang-00
Presenter: Reza Rokui / Tarek Saad
[on Connectivity Matrix - Option 1 slide]
Kireeti Kompella : What does the blue matrix imply? Is it multicast?
Reza Rokui: Yes, there is data replication. We are looking for clarity in the definition.
Kireeti Kompella : Difficult to describe the SLOs for multicast connections in this manner. Characteristics of the paths could be different (e.g., delay).
Reza Rokui : Multiple SLOs should be supported; Option 2 should cover this.
[on Connectivity Matrix - Option 2 slide]
Xufeng Liu : I’m against multiple connectivity matrices in the same slice. It is better to go for multiple slices, each of them with single connectivity matrix. The customer can request multiple slices.
Reza Rokui : In the model we are considering single matrix for exactly that reason.
Italo Busi : If option 2 is allowed you have 3 steps when a packet comes in on the access link: (1) to know from which access link the packet is coming; (1) to understand to what NSE the packet belongs to; (3) to what NSE the packet is delivered. In Option 1 you only have two steps.
Reza Rokui : Agree with the observation.
Draft: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-ns-packet-04
Presenter: Tarek Saad
Jie Dong : Need to resolve Terminology concerns. Need clarity on the terms - Slice policy, slice policy modes, slice policy topology, etc. Comment raised in the mailing list. Aso about slice aggregate, usage in the text has changed. It is important to clarify this change.
Tarek Saad : There is sufficient text describing the terms in the document. In the current version, the distinction between slice aggregate and network resource partition is clearly highlighted. That said, we inted to maintain terminology alignment with framework draft.
Zhebin Li (Robin) : Slice aggregate is confusing. The scope of the slice aggregate is not clear.
Lou Berger : Please take the question to the list (audio issues). Discuss with Zafar Ali about potential merging of drafts.
Draft: https://datatracker.ietf.org/doc/html/draft-dong-teas-enhanced-vpn-vtn-scalability-04
Presenter: Jie Dong
Tarek Saad : I would like to see more alignment with the terminology adopted in the WG before moving for adoption. I’d like to have only Network Resource Partition and not use VTN. Adding VTN ID in the packet is restrictive.
Jie Dong : Agree on terminology alignment. Both data plane mechanisms (resource-aware segments or VTN resource ID) are possible, they have different scalability implications.
Lou Berger: Out of time. Please take additional comments/questions to the list. We will also be taking the question on adoption to the list. Please don’t wait for the adoption call if you have objections – please state them on the list.
Draft: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-slice-policy-02
Presenter: Tarek Saad
Dhruv Dhody : Posted comments on the chat regarding terminology. The term slice policy does not make much sense to me. Need to re-look the terminology. YANG model is also confusing. When talking about rate and shaping, the model does not read very clearly.
Tarek Saad: If the description is thin, we will add more details. We will take take input from the list regarding terminology and edit accordingly.
Zhenbin Li (Robin) : The model depends on solution in the data plane and control plane. This dependency should be solved before determining the data model.
Tarek Saad: We are aligned with framework draft. Please, raise specific pòints with respect to where we are diverging from the framework.
Zhenbin Li (Robin): For example, how to encapsulate the ID and how many bits need to be used for this ID needs to be determined.
Tarek Saad: There are multiple options there and appropriate references are specified. We can take this offline and I can point you to the references.
Bo Wu : Policy model can be used on a device or a controller. The current model seems to recommed using a bandwidth profile for a given network resource partition.
Tarek Saad : The model allows configuring different BW profiles. This is the reason why we have introduced topology filters.
Bo Wu : This is not clear in the model. Network resource partitions seem to have only control plane resource, no data plane resoruces are associated with such partition
Tarek Saad : Data plane resources are part of the model. Examples are needed in the document. Point taken.
Lou Berger: Looking for followup discussion on the list
Draft: https://datatracker.ietf.org/doc/html/draft-geng-teas-network-slice-mapping-04
Presenter: Reza Rokui
//insert slot discussion notes here
Kireeti Kompella : Is it necessary to have an actual ID in the packet? Could it not be based on 5-tuple mapping?
Reza Rokui: It can be so, we are not implying there is an specific ID in the packet.
Luay Jalil : Consider multiple DUs talking to multiple CUs, etc.
Reza Rokui : Point taken.
Lou Berger : Please take the response to the list and discuss it there.
Draft: https://datatracker.ietf.org/doc/html/draft-li-teas-e2e-ietf-network-slicing-01
Presenter: Zhenbin Li
//insert slot discussion notes here
Tarek Saad : Question about the word “framework” in the title. Is this a “new” framework for IETF Network Slicing?
Zhenbin Li (Robin) : This is the realization framework for e2e network slice spanning multiple domains.
Tarek Saad : I was expecting this would be covered by the existing WG adopted IETF NEtwork Slices draft
Zhenbin Li (Robin) : We were not clear where the boundary is with respect to the existing document.
Lou Berger : look what is missing from existing framework docuemnt and propose text there, rather than having a standalone document. Provide response on the list.
Draft: https://datatracker.ietf.org/doc/html/draft-bestbar-teas-yang-topology-filter-02
Presenter: Vishnu Pavan Beeram
//insert slot discussion notes here
Susan Hares : There are routing filters in routing models and flow filters in BGP. How do compare these topology filters?
Pavan Beeram : The mandate for topology-filters is very simple. Couple of use-cases are being targeted – one is to use this in a TE computation-profile and compute paths on a filtered set of topological elements, the other use-case is to use this to associate a filter topology with a network resource partition.
Susan Hares : how does this differ from routing filters?
Pavan Beeram : The topology filter construct filters network topologies, more specifically TE aware native and customized network topologies that may or may not be learnt via routing protocols. If the relevant topology database is maintained as a RIB, then routing-policies can play a role in filtering the entries in the RIB. But that isn’t the target implementation for this draft. That said, will take look at the other specified references and see if there is anything that can be leveraged.
Lou Berger : Please continue the discussion in the list.
Draft: https://datatracker.ietf.org/doc/html/draft-li-teas-intent-based-routing-00
Presenter: Zhibo Hu
//insert slot discussion notes here
Lou Berger: This is new work. Not sure if the work is part of TEAS. Take the comment to the list. More discussion needed.
Loa Andersson: This seems to have a strong TE relation, TEAS seems to be the right starting place.
Loa Berger: This is early work. We will coordinate with the AD and see where this goes. We would also be interested in inputs on the list.