# Administration

Padma/Luigi/Alberto
- Agenda Bashing
- Status reports for WG drafts
- Rechartering Status
- 20 Minutes (Cumulative Time: 20 Minutes)

**Luigi**: There is a new RFC since last meeting, RFC9437, congrats to the authors. We are rechartering and there are a few documents close to be done. We will discuss all this.  
**Luigi**: Any comments on the agenda?  
**Dino**: Marc is presenting the mobility draft.  
**Luigi**: Sorry, I'll fix the slides.  
**Luigi**: These are the charter milestones. If we are early is good, if we are late, we need to discuss and renegotiate. Any comments?  
**Dino**: I'd move geo-coordinates and put it with name-encoding. Because Alvaro already went through the process, and those two drafts are simple. If they can be process by Jim and company together, we can get them out of the way.  
**Luigi**: We can move geo-coordinates to March 2024.  
**Dino**: With respect to geo-coordinates Alvaro said it was ready for IESG. There was one comment, I reflected that comment three IETFs ago and it went into a black hole. It should have been submitted last year.  
 
**Padma**: There is new work coming in and there are things like Reliable Transport which might impact other features. We should take that into consideration before we move. Let's make sure we don't push out a document and end up realizing the change in transport has an impact. A request to everybody, for all the docs we are submitting from now on, look at the broader impact of those changes.  
**Luigi**: Something we discussed in the routing area. Sometimes documents get stuck after we pass the last call. The idea is to ask for early reviews as much as possible, so documents don't get stuck after last call. We will try to do this in a proactive way.
 
**Jim**: One thing you need to mention is that there were two documents that went historic.  
**Luigi**: They were EID Block and EID Block Management Guidelines. This was an experiment; and the block went back to IANA. We moved these documents to historic since they were not used.  
**Luigi**: Except for geo-coordinates, it seems there is agreement on the charter. After the meeting we'll pass it to Jim for the IESG process.
 
# LISP Reliable Transport
- https://datatracker.ietf.org/doc/draft-ietf-lisp-map-server-reliable-transport/
- 10 Minutes (Cumulative Time: 30 Minutes)
- Balaji Pitta Venkatachalapathy

**Luigi**: About requesting WG last call. The chairs have started to review the documents, including this one, and we feel there are a few missing parts which we would like to fix before going for last call. We will send you a full review in the coming week or two to point out what we feel is missing and what should be clarified. Then we can go forward with last call.  
**Luigi**: If you want to move it to standards track and there is some experience deploying it, we should add some text in the document that says it has been deployed and used. There should be some information on why we are moving this from experimental to standards track. Let's put it on revision needed and we'll send you the review to move it forward.
 
# LISP L2/L3 EID Mobility Using a Unified Control Plane
- https://datatracker.ietf.org/doc/draft-ietf-lisp-eid-mobility/
- 10 Minutes (Cumulative Time: 40 Minutes)
- Marc Portoles Comeras

**Dino**: When you said ''multihoming'' in the split horizon check, you said it for broadcast, do you also mean unknown unicast as well? Is that as in the spec?  
**Marc**: I should extend the spec; I was assuming it.  
**Dino**: And you refer to split horizon, but you don't actually say how it works. I'm wondering how it works. There's one forwarder that then sends it to all other sites that are part of the same VLAN. But it also comes back to the XTRs for that site where the source is. Right? First question is, we are going to load up the underlay with packets that are going to come back to the site that are going to be dropped by the ETRs on that site. That's unfortunate. But can the ITR know that it shouldn't replicate to the other RLOCs because it knows it's part of its site from the discovery mechanism? So they don't even leave the site. They'll never come back is the question. It's probably more efficient to do it that way.  
**Marc**: When we are doing unicast replication, we could do something like this. If the underlay is multicast, then what we can do is what we recommend.  
**Dino**: If the underlay is multicast, the other XTRs shouldn't join the group so they won't get it.  
**Marc**: We recommend it.  
**Dino**: If the underlay does multicast, it's going to be more inefficient.  
**Marc**: Yes.  
**Dino**: Because it is the underlay multicast group mapping to all broadcast or all unknown.  
**Marc**: That's the problem. Normally, you switch to multicast when you have a lot of XTRs.  
**Dino**: I think we need to spec that carefully, because there's a lot of details there that aren't clear. But if we're replicating unicast on the underlay, what the ITR gets back from the Mapping System could be all the RLOCs to all the other sites for the VLAN except for the other RLOCs in the same site. Since we have the local list, you can filter that out before you put it in the map-cache. When you map it to multicast it is ok because you are going to hit everybody else. There is a source-based solution and a received-based solution when the underlay is multicast.  
**Marc**: Yeah. I'll document that in the next version.  
 
**Padma**: When you talk about the cache miss, have you ever considered how to prevent the package loss? Because there's a way.  
**Marc**: I would say this is somehow inherent to LISP in general. If we have a cache miss, we need to decide what to do with that target.  
**Padma**: You had all those steps where the flows were L3. The Mapping System after receiving the new registration should already know who the next guy is, before you send it to the next. We should go and relook at that piece. Whether you can use that information and forward it directly, so you never get a cache miss. I've noticed a number of things like that, where we can make the draft better, but I wanted to bring this one up.  
**Marc**: Something that we have implemented at Cisco, but, again, not in any draft, is that you have one default guy that you preload with everything. It's like a combined Map Server and xTR, that you can always forward to. You don't have a packet miss but at the same time, you don't need to flood it to entire network.  
**Padma**: There are plenty of things that are hacks, or things that are deployed to actually solve these problems, but they're not documented. For somebody who's reading it, you see the holes, but you don't see what is the mitigation measures that are being taken. Especially if this is going to standard track, you really have to write those, but you also need to have some analysis of some of these things that are downsides. I think there are ways of improving certain mechanisms that are in this draft. I'll send you my comments.  
**Marc**: Ok, if you have a list, I'll be happy to. Thanks for the comments.  
 
# P4-LISP: A P4-Based High-Performance Router for the Locator/Identifier Separation Protocol

- https://atlas.cs.uni-tuebingen.de/~menth/papers/Menth23c.pdf
- 10 Minutes (Cumulative Time: 50 Minutes)
- Michael Menth

**Dino**: Did you test 400G?  
**Michael**: No, we don't have the hardware.  
**Dino**: And if you get it, will you test it?  
**Michael**: Sure.  
 
**Dino**: Will you consider doing this for multicast?  
**Michael**: We do multicast for Tofino, but we didn't do that for LISP we did it for BIER. For various flavors of BIER.
 
**Marc**: On one slide you said you leave the punt rate to one packet per second, and then you had that performance slide where you say you reach 150 packets per second.  
**Michael**: When you have a specific EID, you can request the mapping for that specific EID only once per second, but you can request multiple different EIDs within a second. Because you need to resolve multiple EIDs and that needs to be done instantly. For a specific EID, only a single packet is forwarded to control plane per second.  
**Marc**: You filter per destination. You are able to filter on a per destination basis.  
**Michael**: We filter directly on the data plane to protect the control plane. The control plane supports 125 packets per second, just different request. When you start a stream, constant bitrate to certain EID, and you would forward all of them to the control plane, the control plane would be overloaded.
 
**Marc**: Any plan to implement EID mobility support? This will entail detection, not only resolving a remote address but detecting what is locally connected to you. The draft I just presented. The rest of the draft talks about detecting local hosts; and when they move around converging the network for that.  
**Michael**: We have not looked into that.
 
**Luigi**: You have shown only examples with IPv4, is also IPv6 implemented? Did you try IPv4 EIDs with IPv6 RLOCs or something like that?  
**Michael**: I think we have implemented only IPv4.
 

# LISP Multicast Overlay Group to Underlay RLOC Mappings

- https://datatracker.ietf.org/doc/draft-vdas-lisp-group-mapping/
- 10 Minutes (Cumulative Time: 60 Minutes)
- Dino Farinacci

**Marc**: Let's say the document is adopted by the WG; are you suggesting we update the naming, everywhere we use S,G groups, to the new notation?  
**Dino**: Do you mean in the entire document set or just in 6831?  
**Marc**: For example, in new drafts that come, like the mobility one.  
**Dino**: Should we accept the new naming convention for future documents? I'd say yes because we need to distinguish between them. Because it was very much assumed in 6831 that G and the outer G on the underlay were the same value. I remember doing this back in the day running IPv4 multicast over ATM and Frame Relay and SMDS. We always had this many to one mapping where you have all these groups that you want to map to something on the underlay. Do you want to have one to one, one to many, many to one? Now with this terminology on the Mapping System, we can do all those things. And the provider will say, you have 10 groups and they're all going to the same sites. Why do I have to have 10 pieces of state in the underlay, I only could have one.  
**Marc**: Between the two mappings that you propose, does the document prefer or recommend one of the two? Normally when hashing, debugging is a little bit more complicated, because you don't know when something is broken.  
**Dino**: Do you mean hashing is good?  
**Marc**: If I had to choose, I would choose the Mapping System based because it's very explicit. It says ''this maps to this''. I was just wondering if the document is suggesting one.  
**Dino**: The document didn't suggest it. It just said if you wanted edge-based versus provider-based, you use one versus the other. But you have a good point. The GID takes a 256 bit hash and then takes the lower 32 bits in the IPv4 case. What if multiple hashed to the same value, and you didn't intend that. Then that could be a bug, arguably. Maybe we will list in the document pros and cons and create a slight preference towards the Mapping System. There could be a potential collision situation that happens with the hash based. The collision won't happen with the Mapping System case, but a misconfiguration could cause it. Choose your poison. But those are good updates, we can fix the spec for those comments.  
**Luigi**: We are supposed to revise the multicast documents and move some of them as a standard track. It makes sense to have a unified terminology. Put it in the documents, we will figure out the details. Unified terminology will be helpful.  
**Dino**: If we adopt this terminology from this document, we go back to 6331 and use the same.  
**Luigi**: Exactly. In the new set we will put the terminology somewhere.  
**Dino**: In the three documents, yeah.  
**Luigi**: And we don't need to discuss this now.  
**Dino**: Okay.  
 
**Padma**: One thing I've noticed is that there are multiple cases listed, but one that's not listed is if the bad actor actually uses a true timestamp. And how do we distinguish for that? If it uses an invalid timestamp, it is easy to find it. But if it is not using an invalid timestamp, he's going to be actually constant here.  
**Dino**: Are you saying timestamp or hash?  
**Padma**: The timestamp to give it a priority. That's what you have written here, a bad actor could send an invalid timestamp giving it a tie breaking priority when the group address collision occurs.  
**Dino**: Are you talking about GAAP?  
**Padma**: Yes.  
**Dino**: Oh ok, complete different topic.  
**Padma**: When we're talking about this, we also need to talk about what failures are happening and how those failures are getting in.  
**Dino**: Let me rephrase your questions. GAAP is going to allocate an address to the applications, that's GEID. Does that have effect on this? It does because that's decentralized, and you don't know what the group addresses are going to be until the application start to name. The Mapping System based one can't a priori know what it is. You could only use hashes. That's an advantage for hash based now.  
**Dino**: I didn't link the two different working groups together. We need to discuss and think about what the implications of those are. Great question. Really good question.  
**Dino**: Stig, do you have any opinions on this? That's the multicast expert in the room.  
**Stig**: I had one thought, but I'm not sure if it's a good idea, but you could potentially, instead of putting the GID in in the mapping system, you could put the application ID. Mapping System would control which underlay group to use for that application.  
**Dino**: But we get a data packet with two IP addresses in it, source and destination. Then we'd have to map that thing to something else that maps to that.  
**Stig**: True. It's an interesting problem.  
**Dino**: We should bring this up in the PIM working group when talk about GAAP.  
**Luigi**: We'll take it offline. We'll meet again in Brisbane.