MPLS WG minutes @IETF 109 (version 00) Friday, November 20, 2020 (+07) 12:00-14:00 Friday Session I 1. Administrivia & WG Status Tarek presents the WG state slides… Regarding RMR draft: Tarek: It’s controversial. It was in the IESG but returned back to the WG. Loa: The chairs were discussing the state and about how to process the draft, no conclusion yet, will keep discussing on it among the chairs, once determined, a statement will be sent out by the chairs or doc shepherd. Regarding the directed draft: Tarek: It’s also controversial.It’s been lingering for a while. Nic will arrange a conference call to discuss on how to handle it. Nic confirmed. Regarding the andersson-mpls-iana-registries-stucture: Loa: Discussed with IANA people, the current tool does not support one more hierachy, will continue discuss with IANA and more people on this. Loa: Received request to progress all SLF related drafts from the authors. That means we need to do WGLC or WG adoption on relevant drafts. Stewart: ? Loa: will check all SFL relevant drafts. Adrian: four people in the queue. Stewart: two SFL drafts in the current since last IETF meeting. Loa: will handle them in one or two weeks, they are next in line. Kireeti: Comments about larp and nofrr. We are working on larp filling in something(e.g., restart, robust, etc.) that we said we’d work on but have not yet. For nofrr, we asked earlier allocation of codepoint. A response indicates that we should make it WG doc firstly. We are working updates to address the comments received from the mailing list. The question is: what else do we need to do? Tarek: According to the MPLS WG process, mpls-rt review first, and then decide whether WG adoption will be issued. It will take weeks. Loa: How big in terms of pages of nofrr draft? Kireeti: 8-10 pages. Loa：How important is the earlier allocation? Are the implementation going on? Kireeti: Yes, we have a prototype. It’s related to microcode. It’s not just prototype, we want to make it for real, esppeically in EVPN use case, there are issues when the CE dies, you get a loop. Loa: Will read the doc and speed up the process through WG chairs review process. Shraddha: Working an update on the inter-domain oam draft, mainly about the iana registration stuff. The revision is done and ready for WG adoption. Trying to give updates about the draft-ietf-mpls-epe-oam. Tarek and Loa: Don’t hurry, it will be dicussed in the follow-up slides. Greg: Confused by the datatraker web page that shows the p2mp-bfd draft is marked as candidate WG adoption ? Loa: Once start mpls-rt review or the chair starts to review a draft, we will mark the relevant drafts as “candidate WG adoption”. It’s somehow indicates that the draft is ready for WG adoption. Loa：We also a TEAS RMR doc that also depends on the base RMR doc. We need to coordinate with the TEAS WG chairs. They need to follow what we’re doing. Loa：Asked the co-authors of osfpv3-code point draft to refresh the draft; Nagendra:will update draft in one or two days. Loa: Question to Stewart, what is your preference on the sequence (regarding the draft-ietf-mpls-rfc6374-sfl and control doc)? Which one do you want to progress firstly. Stewart Bryant: draft-ietf-mpls-rfc6374-sfl refers to the control doc, means that you may need to progress both together. Loa: But it will take a long to get the control doc to WGLC state from an individual draf. May I start to do WGLC on draft-ietf-mpls-rfc6374-sfl? Stewart: Please go ahead to do that. 2. MPLS Data Plane Encapsulation for In-situ OAM Data https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam-sr-03 Rakesh presents the slides… Greg Mirsky: Can you explain the interpreation of the two eSPLs? Why two eSPLs are used for each use case? Rakesh Gandhi:they are used to indicate that there will be iOAM data follows. Greg: But, only one eSPL for entropy label case. Rakesh Gandhi: Try to solve the hashing issues, hence to use the iOAM and Flow Indicator Label. Greg: You propose to allocate two eSPLs, what’s the second eSPL use scenario? Rakesh Gandhi: Because we need two lables to identify different types of ioam payload, can be discussed in WG mailing list. Greg: Does it make sense to have only one label? Rakesh Gandhi: if WG thinks it is fine, ok for me. Take the discussion to mailing list. 3. Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Path Segment Identifiers (SIDs) with MPLS Data Planes https://datatracker.ietf.org/doc/draft-xp-mpls-spring-lsp-ping-path-sid-00 Xiao Min presents the slides… Xiang Ji: two questions, 1. Path SID is list of SIDs, how to align the FEC stack with the label stack and do FEC check procedure? 2. We may need a type filed in the sub-TLV to separate the type for IPv4 and IPv6. The current design is not a good practice and not flexsible for future modifiction. It’s better to align with other relevant RFCs (e.g., RFC8029?), not good way to use one sub-TLV for IPv4 and IPv6, either to use two types or to differentiate the type. Xiao Min: does not understand the question. Xiang: according RFC 8029, the label number if the stack should match the number the FEC stack. how many SID will be carried, just one Path SID, or carry all related labels + Path SID? Xiao Min: later chekck the RFC8029, come back to mail. Zafar Ali: not to complex the work to define new SID, why not just reuse the generic SID TLV, suggest to draft-generalized oam for reference to design the sub-TLV. more offline work together. MIN: the two drafs(Generic sub-TLV and this draft)compliment to each other. the generalized-oam draft cannot be used to valdiate the sync between data plane and control plane. This draft may be needed as well. Zafar Ali: Personlly does not like the idea for validating synchronizaiton, although it was designed at the very beginning. But anyway, we should talk more about how to do data plane validity by using the generic lable sub-TLV. Xiao: Let’s talk more offline. Mach Chen: What is the purpose to validate the path segment? Xiao Min: The purpose is to check the Path SID that is allocated to the ingress can be forwarded to the correct egress node. Then the egress check whether the Path SID is that correct segment that’s allocated the ingress node. Tarek: Then you can allocate it for per-policy, why per candidate path and per segment list. Xiao Min: we follow the way defined in draft-idr-path-segment Xiang Ji: this is more about control plane stuff, why not just do it in control plane for validation? Min: maybe there is other method to validate this, we will see. Cheng Li: it is valuable to do something with path segment, will take time to chek the draft. 4. BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP https://datatracker.ietf.org/doc/draft-mirsky-mpls-p2mp-bfd-12 Greg Mirsky presents the sldies… No comments from the floor. 5. Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms https://datatracker.ietf.org/doc/draft-rathi-mpls-egress-tlv-for-nil-fec-01 Deepti N Rathi presents the slides… Xiang Ji: conflict with SR generic FEC TLV. why not use the existing IPv4 and IPv6 sub-TLV? how we handle the adj-SID if the last sid is not a prefix SID? how to handle the Binding SID case? Another thinke, you have two TLVs(Egress and FEC Stack TLV), how to align the FEC stack and Label Stack? According to RFC8029, the number of labels and number of stacks should match, so this breaks it. Deepti Rathi: For complete label stack, only one nil FEC is sent. Does not make sense to send multiple nil fec. Nil label can be sent with one label or multiple labels according to RFC 8029. Xiang: restate that the number of labels and the number of FECs should match. Deepti: When using nil, that rule does not need to be followed per the RFC. Xiang and Deepti keeping debate one the above question… Tarek Saad: better to take it to ML. Zafar Ali: be good to aligh with authors of draft-generic-fec-TLV,instead of introducing new FEC sub-TLV, why not just reuse the sr generic sub-TLV, good to have discussion further. Deepti: OK. Shraddha:You do not have a generic way of being able to travserse the data path without having to validate the syn between data plane and control plane. The SR generic sub-TLV may not work in this case. Tarek: suggest the authors of the two drafts to dicuss further. 6. Segment Routing Generic TLV for MPLS Label Switched Path (LSP) Ping/Traceroute Presenter: Nagendra (5 min) https://datatracker.ietf.org/doc/draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-04 Nagendra presents the udpates and asks for WG adoption Greg Mirsky: segment must install adj SID info of the directly connected nodes? will be thousands of neighbors. should be clearly stated and it is a tradeoff compared to the cost. Nagendra Nainar: It’s not require to maintain all the adj sid assigned by all the nodes, it’s only the adj sids assigned by the directly connected nodes. It can rely on the existing IGP DB, it’s up to the implementaiotns. Xiang Ji: if packets come from the backup interfaces, how to handle this situation? Nagendra Nainar: haven’t thought about this. Will add some text later. 7. MPLS-based Service Function Path(SFP) Consistency Verification https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification-01 Yao Liu presents the slides... No comments. 8. The Use of Path Segment in SR-MPLS and MPLS Interworking https://datatracker.ietf.org/doc/draft-xiong-mpls-path-segment-sr-mpls-interworking-02 Yao Liu presents the slides... Tarek: You will creat per-path state on the transit nodes, this is not aligh with segment routeing that does not create per-path states on transit notes. Yao Liu: Yes, but the states only on the border nodes, just like binding SID. Tarrek: But Binding SID is not per-path state. 9. Export of MPLS-SR Label Type Information in IPFIX https://datatracker.ietf.org/doc/draft-tgraf-ipfix-mpls-sr-label-05 Thomas Graf presents the slides... Tarek: What will be left if you take SR SID out? Thomas: just label type. Tarek: would it provide protocol like ISIS，BGP？ Thomas: yes, that’s why the IE46 would provide, it defines which label protocol provided the label. 10 Generic Transport Functions https://datatracker.ietf.org/doc/draft-zzhang-tsvwg-generic-transport-functions-00 Kireeti Kompella presents the slides... Stewart Bryant: Puting a type field in MPLS is architecture change to MPLS. We need a proper discussion about that rather than sort of sneeaking it in. If we separate the tyep from the fragmatentaion method, we should seriously condiser upgrading RFC4623 to add additional field. RFC4623 is a standard way to do PW fragmentation in this context. We should do the right thing for the mpls arch. Kireeti: Explain more about the type field？ Stewart: we have avoided having next header in everything else we’ve done in mpls by making what follows a function of the bottom label, now they are on the top. Kireeti: Need to terminate the label stack to process GFH and come back to process the rest of the stack. Just like putting a fake end of stack label in the stack. Stewart: we need to understand what’s the consequence to do as that way. The meeting time used up, Tarek ask to take the discussion to the list. Stewart and Kireeti keep discussing on the mic… End.