MPLS WG Draft Agenda for IETF 110 (version 00) Monday, March 8, 2021 (UTC+1) 13:00 -15:00 Monday Session I Slides: https://datatracker.ietf.org/meeting/110/session/mpls/ Codimd for Notes Taking: https://codimd.ietf.org/notes-ietf-110-mpls/ Meetecho: http://www.meetecho.com/ietf110/mpls/ Jabber: xmpp:mpls@jabber.ietf.org?join 1. Administrivia & WG Status Speaker: WG Chairs, 10(mins) Tarek went through the WG status, no questions from the floor. 2. A YANG Model for MPLS MSD Draft: https://datatracker.ietf.org/doc/draft-qu-mpls-mpls-msd-yang/ Speaker: Yingzhen Qu (10 mins) Tarek: I saw there was a MSD type, is it a dataplane type? Yingzhen: It's a MSD type, there are two types defined. One is the base MPLS MSD that identifies the maximum number of labels on node can read, the other is the ERLD-MSD. 3. Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms Draft: https://datatracker.ietf.org/doc/draft-rathi-mpls-egress-tlv-for-nil-fec/ Speaker: Deepti N Rathi (10 mins) No question from the floor. Deepti requested WG adoption, Tarek said that the request recorded and the chairs will discuss how to make it forward. 4. PMS/Head-end based MPLS Ping and Traceroute in Inter-domain SR Networks Draft: https://datatracker.ietf.org/doc/draft-ninan-mpls-spring-inter-domain-oam Speaker: Shraddha/Kapil (5 mins) Mach：RFC7110 defines a Reply Path TLV that was designed to carry the specified return path of echo reply. It's better to define extensions based on that TLV. Kapil: I do not see that RFC yet, We can discuss it through email. This is designed for SR network. Greg：Have you read the spring bfd document that introduce non-FEC TLV and define reserve path TLV, it can apply to SR network. RFC 7110 combined with SPRING-BFD draft cover all the cases proposed heere. Kapil: This draft also covers how to dynamically construct the stack. Greg: This is informational. Kapil: Will keep discussing with Mach and Greg this through email. 5. LSP Ping/Traceroute for Prefix SID in Presence of Multi-Algorithm/Multi- Topology Networks Draft: https://datatracker.ietf.org/doc/draft-iqbal-spring-mpls-ping-algo Speaker: Nagendra Kumar Nainar (10 mins) Tarek：Does it cover all flex-algo or just user defined one? Nagendra: Cover all. 6. MPLS-based Service Function Path(SFP) Consistency Verification Draft: https://datatracker.ietf.org/doc/draft-lm-mpls-sfc-path-verification/ Speaker：Yao Liu (10 mins) Nagendra:Seems that the draft is targeting to both leagcy MPLS-based and SR-based SFC. I don't think that the theroy can properly work for SR-based SFC.My question: How does it do validation in the case SR-based SFC? Yao: This draft only talks about MPLS-based SFC, the SR-based SFC is supposed to be in another draft. Nagendra: Want some clarification on SRSR- Greg: Currently, the document covers only leagcy MPLS-based SFC(RFC 8595). The solution for SR-based SFC is open for dicussing, needs feedacks and suggestion from the WG. Nagendra: This draft seems cover both MPLS and SR-based SFC. Loa: Regarding slide 4, existing sub-TLVs are normally defined for both TLV 1 and 21, does this also apply to these new defined sub-TLVs? I will take it to the list. Tarek: My question is about the multiple presense of the GAL in the stack, the draft proposes to carry multiple GALs in the stack, but this is different from what GAL/gACH was defined, where the GAL must be put at the bottom of the stack, gGAH immediately follows GAL. Are you going to update this? Yao: Yes. This is required in the document, we are also considering to use other SPLs. More discussions needed. Tarek: Some hardware will assume the specfic bits (first nibble of gACH) will follow the GAL, but you draft change that. This has to be throught of more. Yao: OK. Adrian (from chat) If I understand this draft, the intent is to use TTL-->0 to detect an OAM packet? 7. MPLS Data Plane Encapsulation for In-situ OAM Data Focus the aspects not discussed in the joint meeting Draft: https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam-sr/ Speaker: Rakesh Gandhi (10 mins) Rakesh requested WG adoption and pointed out this draft will be disscussed in the Joint Meeting. Kireeti:I just want to give a quick pointer forward to the draft I have below, regarding the SPL being used in this draft, and it aapplies to a few other drafts presented today. I would ask people to wait for those slides and what the proposal is and how that changes their requests for SPLs. Tarek: Regarding E2E SPL, since you are going to assign new gACH type this iOAM meta data, why not just reuse GAL? Rakesh: The way GAL defined for egress is that it will punt the packet to control. In the iOAM case, the meta data carried in the data packet, and the data packet should be forwarded to downsteam. The GAL is mainly designed for OAM packet that will be terminated at the egree. That is what GAL was defined, there are existing implementations. Once change that, there will be some implication on the existing network. TakeK: OK. How to handle when GAL and the new SPL are carried in the same packet? What's the order and processing of the payload of MPLS? Rakesh: GAL is carried in OAM packet, the iOAM is carried in the data packet. There is no scenario that GAL and iOAM will be put in the same packet. If there is a scenario, we can talk about it. Tarek: I do not have use case yet, I am not sure that this will never happen unless you explicitly state (MUST NOT) in your proposal. Rakesh: We can explictly state that GAL is meant for OAM packet and this iOAM is meant for data packet. Tarek: OK, we can follow up on the list. Stewart(from chat):We need to discuss the whole subject area of MPLS metadata before we can consider anything for WG adoption. We need build the full matrix of possibilities. 8. Carrying Virtual Transport Network Identifier in MPLS Packet Draft: https://datatracker.ietf.org/doc/draft-li-mpls-enhanced-vpn-vtn-id/ Speaker：Jie Dong (10 mins) Tarek: What if the transit nodes can not read beyond the end of stack? Any considerations about this? Jie: I think this belong to the capability advertisement, each node need to advertise whether it can support the capability and process the VTN header after the label stack. Is that what your mean? Tarek: No, my question is about readable depth. If I cannot read beyond the readable depth, I can not reach the VTN ID. Other solutions carry the slice/aggregate ID in the stack, not end of the stack. I think that more consideration about where to carry the identifiers are needed. Jie: There are several opitons for carrying the IDs, each has its own pros and cons. Place it after the stack gives more flexable to define the format. Agree that more discussions on each candidate are needed. Stewart: Point 1: We should add this to the long list of metadata after the stack, we need to determine what we can do for the community. This is one of the reasons for the Friday's Joint meeting. Point 2, regarding the first nible (0x0010) after the stack. Based the agreement with the INT area AD, we will take (0x0000 and 0x0001) , and we will not take more; now BIER took another one. If we want to take another one, we need to discuss this with INT. Which one we can safely take in order not to make confilcts. Jie: Thanks for the useful informatin, we do not consider that yet. Jeff：Needs to consider ELD as well. Jie: Agree. 9. Using Entropy Label for Network Slice Identification in MPLS networks Draft: https://datatracker.ietf.org/doc/draft-decraene-mpls-slid-encoded-entropy-label-id/ Speaker: Julien Meuric (10 mins) Stewart: RFC 6090 specifies that the TTL for the EL must be zero and is not used for forwarding. Need to make sure that we are not derogating any security promomises that we made in the past. Julien: OK, I see you point, I think it's relevant to make sure it will not break anything. Are there any specific issue about this? Stewart: This was about makeing sure that we didn't get rogue packets in the network. That's why it was done and it is about whether one of those packet could ever get loose in the network with a high TTL and go somewhere strange. I think it needs a much bigger consensus that it is safe to remove that safety feature. Junlien: OK, that's an open issue to be tackled. Encourage to discuss it on the mailing list. Jie Dong: The solution can avoid the increase of label stack depth, while has some limitations on serval aspects(e.g., Slice ID length, affection to existing functioin etc.). Does there needs a way to discover the capabiltiy of the new introduced function for transite nodes? Julien: The processing is transparent to the nodes, it's not necessarily required, and not considered in the current document, maybe needed. Jie: It's transparent for Entropy processing, but not for network slicing. Julien: Yes, that may an useful information when do slice selection. Jie: Suggest to use consistent terminology when talk about the same function. Julien: Agree. Jeff:If you use EL for forwarding, then you change the sematic and behavier of the EL that is optional for load sharing, because it just increases the entropy. Now, if it is used for forwarding, it's mandatory to be read. It needs to make sure that it will be read for all nodes along a path. I'd like to see these points addressed in the draft. Julien: OK, I will share this with the authors. Tarek: I don't think that the EL will be used for forwarding, it just carries the slice id information. Jeff: It's for dataplane, it needs to be imposed and read by someone. It needs to be imposiable and readable. Tarek: Yes, totally agree that transit node should be abel to read it and it should be within the readable depth for relevant nodes. Jeff: RFC8662 gave in details on how to compute lables where to insert it and it would be great to see it addressed in the draft. Tarek: Yes, agree. Stewart: Capabiliy advertisment needed. And needs to know what Sliceing wants from MPLS before defining slice identifier for MPLS. Tarek: Agree. Greg:It's risky to reuse the TTL field of EL for non-TTL purpose, capability advertisement needed, more condierations and discussions needed. Julien: Point taken. 10. Multi-purpose Special Purpose Label for Forwarding Actions Focus the aspects not discussed in the joint meeting Draft: https://datatracker.ietf.org/doc/draft-kompella-mpls-mspl4fa/ Speaker: Kireeti Kompella (10 mins) Kireeti did not go through the whole slides, just focused on several slides to introduce the key idea. Stewart: First, a bit worry that you put things in the SPL, while it should be put in the FEC. E.g., for the NO-FRR case, it would be to send the origial packet on the FEC that had the property that it was not to be FRR, and that would be consistent with the existing MPLS Arch and without extensions. Second, regarding the SPL must not be at the top of the stack, there are some case the SPL will be at the top of the stack, eg., GAL in PHP LSP. Need to be careful about backwards compatibility. Athough you meant the new ones must not be at the top of the stack. Third, regarding put other bits and data in the stack. The ITU wanted to do this before, it was sharply reprimanded. We need to justify why we changed our minds on this. Kireeti: I agree that the decsion we made needs to be refunded.We have changed a lot of things in the forwarding path.The idea of deep stacks, of looking beyond the stack, etc. was difficut to do.We don't want to force that decision but we've already gone that path. Regarding SPL never apear on top of stack,the SPLs do twiddle with TC and TTL fields should not apear on the top of the stack. We have talk to brodcom asic, our asic guys about this. Backwards compatibility is important. Haoyu:This is similar to existing drafts that introduce MPLS extension header to MPLS. Encourage the WG to re-examine our proposals as well. Kireeti: I will find that draft and read it. The idea here is that SPLs with data in the stack and there is data beyond the stack. Rephased what idea proposed in the draft. Tarek: please follow up on the list. 11 . Generic Delivery Functions Focus the aspects not discussed in the joint meeting Draft：https://datatracker.ietf.org/doc/draft-zzhang-intarea-generic-delivery-functions/ Speaker：Jeffrey Zhang (10 mins) Jeffery: There will be a presentation on Firday (the Joint meeting with PALS and other WGs). The idea is that it is not only just for MPLS, but for other scenarios. Please read draft and comment! Total presentation time: 105 mins Shuffling time: 15 mins # Note: JOINT MPLS/PALS/DETNET/SPRING session on Friday: ********************************************************************* IETF 110 PALS/MPLS/DetNet/SPRING Joint Meeting Friday, 12 March 2021 - 12:00-14:00 UTC Room:7 120/120 min allocated ********************************************************************** Chairs: Stewart Bryant and Andy Malis Secretary: David Sinicrope Mintues: https://codimd.ietf.org/notes-ietf-110-pals