MPLS WG Draft Agenda for IETF 105 Session 1 15:50 - 17:50 ET Tuesday Afternoon Session II Location: Viger Slides: https://datatracker.ietf.org/meeting/105/session/mpls Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-105-mpls Meetecho: http://www.meetecho.com/ietf105/mpls/ Audio stream: http://mp3.conf.meetecho.com/ietf/ietf1053.m3u Jabber: xmpp:mpls@jabber.ietf.org?join Available post session: Recording: https://www.ietf.org/audio/ietf105/ YouTube: https://www.youtube.com/user/ietf/playlists 1. Agenda bashing, and status Loa and Tarek introduce the current status of WG. 2. draft-hegde-mpls-spring-epe-oam Shraddha Hegde presents the slides. Shraddha Hegde: Which WG should this draft be progressed, MPLS or SPRING? Bruno Decraene(SPRING WG co-chair): There is a similar draft in SPRING WG, and there seems an agreement to merge the two drafts. The definition of the FEC should be discussed in SPRING. Because this draft will asked MPLS code point, I am fine to progress this draft in MPLS WG. Loa Andersson: Report to one WG for each meeting, technical discussion should be in both WGs (MPLS and SPRING).No necessary to present in both WG. Bruno Decraene: A reminder can be sent to other WG when discussing the FEC definition or changes. Sam Aldrin: Are you mandating that this draft depends on another draft? Is another draft is part of the solution? Shraddha Hegde: This draft mainly talks about the definitions of FECs. If you are talking about e2e solution, there needs a way to send response back. We have the next presentation to cover how to send response back to the source. Zafar Ali: For the PeerSet SID FEC, you need to carry all the relevant information of interfaces, there will be a lot of information, how much parameters used as the input? There are too much. I am concern about the complexity involved with this draft. With the current solution, one FEC for each new defined SID, there will be a corresponding FEC sub-TLV to be defined. This is complex. Maybe we can just define one FEC that can cover all types of SIDs. Shraddha Hegde: It is not necessary for the user to input all the local/remote interfaces information. These information is advertised by BGP-LS, there is an entity that learns all these information and knows how to handle it. Loa Andersson: Asked Zafar to send questions and comments to the list. Zafar: You rely on FECs to carry the information, that's the problem... Greg: There is a typo regarding 4/6, it should be 4/16. The local and the remote address should be the same family, suggest to highlight that. And Sharaddha agreed. It's better to describe how to explose all the candidate ECMP paths. Loa Andersson: Since time limitation, asked Greg to send comments to the list. 3. draft-ninan-spring-mpls-inter-as-oam Mukul Srivastava went through the slides(https://datatracker.ietf.org/meeting/105/materials/slides-105-mpls-sessa-ietf-105-interas-oam-sr-network-00). Greg Mirsky: There are still discussions on BFD directed draft. Which uses the similar idea. There is another individual draft in SPRING, which uses explicit SIDs list to carry the reverse path a BFD session. Shraddha: Is that used for LSP Ping (Question to Greg)? Sam: I am OK with the scenarios, but the fundamental question is how the response gets back to the ingress, if the path broken. Loa: Encourage Sam and the authors to continue discussion offline. Zafar: Response to Greg's comment: this idea (specify the reverse path with explicit SIDs stack) is OK for Ping, but may not for BFD. 4. draft-cheng-mpls-inband-pm-encapsulation Fengwei Qin presents the slides on behalf the authors. Tarek Saad: SFL approach solves this. Rakesh Gandhi: IOAM can possibly do the same thing. Fengwei: I will let the authors to answer the questions. 5. draft-gandhi-spring-ioam-sr-mpls Rakesh Gandhi presents the slides on behalf the authors. Tarek Saad: Global label is allocated in the whole network - makes it replacement for the SPL. Greg: Characteristic of MPLS or SR-MPLS how do you distinguish ingress. 6. draft-xiong-mpls-path-segment-sr-mpls-interworking Greg Mirsky presents the slides on behalf the authors. Dhruv Dhody: Why not use binding label instead of path segment? Tarek: Is the path segment maintained e2e? Greg: Yes. Rakesh: The same approach exists in another draft - encourage you to look into it. 7. draft-andersson-mpls-lsp-ping-registries-update Loa Andersson presents the slides. Kireeti: Experimental RFC required was needed at the time. Agree RFC required is the correct one. Greg: Some allocation (popular) make 0 and 255 reserved and not use them. 8. draft-nainar-mpls-spring-lsp-ping-sr-generic-sid Zafar Ali presents the slides. Mukkul: You are trying to pack a lot of information in one thing, which I would not agree. Adj-SID are advertised in BGP-LS. Greg: ECMP is challenging. But how is you method? Shraddha: Nil-FEC is there that can do the same thing. Tarek: Generalizing is OK but not on expense of no passing enough data for the egress to validate - in some cases, you are relying on populating the interface mapping table from config or controller? Zafar: very complex FECs - prefer generic FEC. 9. draft-ietf-mpls-sfl-framework-04 and draft-ietf-mpls-rfc6374-sfl Loa introduces the current status. Three SFL related drafts that expired recently, the main author (Stewart) may not have enough time to continue to progress the drafts. Stewart will introduce the status and issue. I prefer simple solution. Stewart: SFL framework draft is in good shape, it does need much work and could go through to last call. The solution draft is in pretty good shape, it could go through to WG last call except one thing. Will pick up the work next week when I get the resource again. There are many options for control plane solutions. George and I had a draft, it does not require to touch any of the MPLS control planes. Someone asked the RSVP, LDP, IGP based solutions, but I have no energy and resource to work those solutions. There are three options to progress the work: 1) keep tag/label field as reserved for future work; 2) go with the current control plane solution; 3) wait for others to write all relevant control drafts. Tarek: How about using a controller for SFL allocation? Stewart: This solution has merit, since it does not require to touch any control plane protocols. Adrian: 1) All 3 are expired? yes 2) if no implementation, then why take to WGLC? Stewart: Some people said that want them to be published as RFCs. Loa: No implementation for now does not mean there will be no implementations in the future. Stewart: I heard from people that they want RFC and they may build on it. Ryan: Similar action is mirroring SID. I think operators would be interested... Loa: Any idea how to proceed? I personally think we can go along with the current simple control solution. And make it possible that it can be extensible for different control planes. Stewart: Will look through the drafts and make sure they match the instructions. George Swallow: Do we have a requesting process I-D in the initial exchange? If we did, someone may want RSVP-TE, LDPˇ­, then the requirement returns back to RSVP. Stewart: Talk to you offline.