Padma/Luigi/Alberto
- Agenda Bashing
- Status reports for WG drafts
- 5 Minutes (Cumulative Time: 5 Minutes)
Luigi Iannone: PubSub is almost done, waiting for Albert last message and then it will be published, it is in the AUTH48 period. For Distinguished Name encoding Alberto will be shepherd. YANG model authors asked for WG last call and Med sent a few comments, Alberto will take 5 mins on the agenda after Dino to discuss this.
Joel Halpern: You're using LISP Distinguished Name which says that each usage has to say how their name is "distinguished" from other use-cases, so you don't end up with name collisions. I couldn't find anything on your draft, have you addressed this or is it an open item?
Prakash Jain: What we specify on the draft is that the distinguished name can be agreed upon in the fabric.
Joel: I think you'll need to write a little more.
Dino Farinacci: You can say that you are going to "distinguish" the distinguish name by the mechanism defined in the distinguish name encoding draft. Which is to say that rather than agree on the name, which can conflict with other use-cases, you agree on the Instance ID of the VPN, and then you register the default PeTR in that VPN. Make a reference to why this is needed.
Luigi: Authors asked for WG adoption. WG shows rough consensus for adoption (5 raised hand, 2 didn't raise). We'll open a call for adoption in the mailing list.
Altanai: I'm trying to understand the real-life applications of this protocol and how we can avoid flooding which could be a potential issue.
Dino: The definition of IP multicast is, whoever joins are the only ones who get messages. If two of the VMs were to join another multicast group, those two VMs will get messages just for that multicast group, as well for the 'dino' group that all of them are part of. It is not flooding; it is explicitly requesting a multicast stream. And when you leave you get pruned from the tree and the mapping system. If you are running native multicast there is a multicast tree that gets pruned, so packets don't need to go to that end. This is an overlay where there is headend replication being sent whereover it has to be. When these guys leave, they are removed from the mapping system so subsequent packets don't go to the guys who have left.
Altanai: Follow up question, when does the group gets terminated? When the last person exists or is there a timer when one can reconnect?
Dino: Once you exit the application, that causes an IGMP leave to be done. That message basically goes to the LISP xTR that's collocated with the application that tells the mapping system to remove it from the mapping system. As soon as that happens, that node doesn't get data any longer.
Altanai: Ok.
Alberto Rodriguez-Natal: This is to comment on the mail that Med sent to the list. We asked for WG Last Call for LISP YANG, the document has been stable for several years. The document is aligned with the latest specs in RFCs 93XX. I wanted to get the opinion of the WG on the two points Med raised on the list. One is about having an IANA maintained YANG models for the several identifiers we use, that right now are described in the LISP YANG. The other is about geo-coordinates, it seems there is a YANG model for geo-coordinates. Not sure if it applies here or if we can reuse it. Just raising awareness on these two comments if you have anything to say send comments to the list.
Luigi: I suggest we get help from a YANG doctor.
Alberto: Agreed.
Luigi: I will contact a YANG doctor. We'll refine the document and restart the Last Call on the mailing list.
Alberto: And Dino, you will comment on geo-coordinates, right?
Dino: Yes.
Dino: The lispers.net NAT traversal document was once a specification but was turned into a report of an implementation. After back and forth with Elliot, the ISE, we decided we are not going to make it informational. It is not going to be publish under any IETF context.
Luigi: We have Vina's document.
Dino: And that should be consider a WG document.
Luigi: Yes, long time ago we committed to have a NAT traversal solution. The idea is to continue or restart that work.
Alberto: Something missing on the slide is reliable transport. Reliable transport is a document that has been sitting around for a long time, but it is one of the main documents that LISP production networks rely on. It has seen a lot of deployment and it is something we need to finalize at the IETF. That should be one of the top priorities in any new charter for LISP because people are depending on that to run LISP networks.
Luigi: It is not difficult to add text to accommodate the document, if you say this is widely used. It makes sense to add, but you will also need to work on it and push it.
Alberto: My understanding is that the authors are looking to work on it, but I don't want to speak for them of course. So hopefully we can make progress on the document.
Alvaro Retana: Regarding multicast you are saying the current experimental documents should be merged and published as standards track. Is there any new work on multicast or is the work just republishing into Standards Track. The reason I ask is because if the work is just republishing in standards track, that is covered by the bullet "Standards Track Documents". If there is more work great, but if not that way the charter doesn't look so big.
Dino: In terms of multicast there was nothing new added to the protocols or architecture, all the documents are use-cases.
Alvaro: And I assume in the charter header is going be called out that the WG is responsible for the maintenance of the protocol. So, if there is some new thing that should happen, and it's not covered, it should be ok.
Alvaro: I have some concerns about the applicability documents. The way I read the text on the slide is that there is going to be a document that updates 7215, not necessarily several documents that document how different LISP use-cases might be applied. If you are going to produce multiple documents is better to say you're going to produce multiple documents.
Dino: Do you want to standardize 7215 which means the applicability of LISP at the time it was published, or you want the latest applicability of LISP as of July 2023?
Luigi: 7215 is deployment considerations, it is informational. The document we produce will be again informational. But is a use-case that is pretty old and that is not the current use-case for LISP, so it makes sense to update with something that is recent and meaningful.
Alberto: Are we talking about a document that includes the information from ground-based lisp, Nexagon and so on? If we want to have a single document that covers those use-cases plus additional ones we are going to end up with a huge document.
Luigi: We don't need to document everything. Maybe the WG should decide a small set of meaningful use-cases.
Alberto: If this is supposed to be a document that is just giving ideas to people on how to use LISP that is fine. But for those particular use-cases, that other organization bodies like ICAO or AECC might use particular details, I think we should still have all the details for those use-cases on their own documents.
Jim Guichard: I want to clarify LISP Applicability, I just looked at 7215 and that is an experimental RFC. I'm assuming the point is that you want to standardize that RFC and update it with new use-cases, is that correct? If it is, we need to make that clear.
Padma: It is obsolete and we should refresh it. Responding to Alvaro, yes, we want one document, but I think as we can go for a base doc and eventually supplemental documents. Right now, I have no strong opinion one way or the other, but I think in the future there might be supplemental documents.
Alvaro: It would be nice to have a document that gives ideas and talk about deployment model or scenarios. Versus having documents from the WG on how to use LISP on datacenters, satellites, cars, airplanes, etc. Those documents don't change LISP, they tell you how to use it. If that is what the WG is going to work on, make sure you say that.
Luigi: I don't believe we need to have several documents, because a lot of them will somehow overlap. The principles to use LISP are the same, you have some declinations that are specific to the use-case. The counter argument to a document can grow huge, you can have zillions of small documents that add to the same thing. Let's choose the most important use-cases with the principles on how LISP can be deployed; and then in different sections put the details of the specific use-case.
Dino: Why don't we make the applicability document say, this is what LISP can do, and how it does it point to particular documents. If you do that there is no overlap.
Alvaro: What is the status of those other documents, are these other documents working group documents? Or are they other documents that can be published though the IESG? Because we don't need WG consensus to reflect an implementation was done.
Dino: What about VPNs, that is so fundamental.
Alvaro: There is an item there for VPNs.
Padma: We don't want a document for every single small use-case. Maybe we can come up with a wording which is better about the scope. The main document should cover a number of cases, only the novel use-cases that are not covered in the document should be new documents.
Prakash: I'm ok if you want to update 7215. We have more than 3000 deployments today using LISP, every day we are talking to the customers there is a new use-case coming. It won't be possible to update everything in one go. We should keep the charter open for the possibility of adding new use-cases or applicability.
Padma: I'm going to share some tentative milestones and that document is way down below, so that should give us some long living document before it becomes a standard.
Robert Raszuk: Completely different topic. As this is the proposed charter discussion I have a question, so far from what I understand, LISP works on the underlay, and it works in the best effort path between xTRs. Anyone here in this WG thought about making optimal routing LISP, so you don't go from source to destination but maybe hop through another transit TR just to get better performance in the data path.
Dino: This is covered by the LISP Traffic Enginering draft.
Robert: Is it already covered? Then fine.
Sanjay Hooda: Coming back on the same topic. From the learnings of 3000+ deployments, we found that there are less than 10 actually the modules that plug this in to make this multiple use-cases. From that perspective is better to describe those 10 building blocks in the document, that way as the document evolves those 10 blocks fit in to setup the use-cases. I'll talk to Dino on what those building blocks are. These are some of the use-cases you cannot solve with any other method.
Jim: We spent most the time with the charter discussion talking about LISP applicability, which worries me greatly. From the WG perspective, it is the other stuff that seems to be important focusing our time on. The only thing with this, it allow us in the charter to have the flexibility to do this, so we need to work on that wording a little bit. This should not be front and center of the charter, I don't want the IESG to think that LISP is just going to do a bunch of applicability documents, which is not wat we want to do.
Dino: There will be an output from the LISP WG called NAT traversal. Which document it is, is becoming more unclear.
Luigi: We work a bit in the applicability bullet and then we share this on the mailing list. Read and look if the milestones are reasonable in time and send the feedback so we adjust accordingly. To me that is the most reasonable next step.
Dino: The order of this, did you make a judgment on the priorities or is it just completeness. Why is LISP NAT second?
Luigi: This is based on the maturity of the documents and the priorities at the same time.
Alberto: I was about to make a similar comment. For instance, item number 7 about merging LCAFs, is that considering just the existing LCAFs or assuming new ones are going to come?
Luigi: There are two documents on LCAF basically, we can put them together and have one standards track.
Alberto: If that is the case, it is super straight forward. There a few other things, for instance 6832bis is going to be easy as well. As long it is in the charter somewhere I'm fine, but same question as Dino, why this order and no other?
Luigi: It is a possible order, but there are other suggestions.
Jim: One comment, and Alvaro correct me if wrong. From a charter perspective these are milestones you want to achieve, but if you happen to achieve one before that date actually it doesn't matter.
Luigi: It is the contrary usually, if we are late we should rediscuss the milestones.
Dino: I have a question for November 2026, could recharter also mean that the WG closes and then there is a LISP-ops group that starts that is solely operation stuff that is done?
Luigi: We'll discuss in 3 years.
Alberto: I think the date for LISP NAT traversal is very optimistic.