An Architectural Introduction to the Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-introduction-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-09-20
|
15 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-09-07
|
15 | (System) | RFC Editor state changed to AUTH48 |
2022-08-10
|
15 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
2022-07-19
|
15 | (System) | RFC Editor state changed to REF from EDIT |
2022-07-14
|
15 | (System) | RFC Editor state changed to EDIT from MISSREF |
2021-09-23
|
15 | Alvaro Retana | This document has been waiting for missing references for several years -- the most recent (-15) version includes changes to the references and minor editorial … This document has been waiting for missing references for several years -- the most recent (-15) version includes changes to the references and minor editorial updates, both intended to reflect the current status of lisp. None of these changes are significant to the content of the document. The WG Chairs (Joel Halpern and Luigi Iannone) and the responsible AD (Alvaro Retana) have reviewed and approved the changes. |
2021-09-20
|
15 | Damien Saucez | New version available: draft-ietf-lisp-introduction-15.txt |
2021-09-20
|
15 | (System) | New version approved |
2021-09-20
|
15 | (System) | Request for posting confirmation emailed to previous authors: Albert Cabellos-Aparicio , Damien Saucez |
2021-09-20
|
15 | Damien Saucez | Uploaded new revision |
2021-08-31
|
14 | Damien Saucez | New version available: draft-ietf-lisp-introduction-14.txt |
2021-08-31
|
14 | (System) | New version approved |
2021-08-31
|
14 | (System) | Request for posting confirmation emailed to previous authors: Albert Cabellos-Aparicio , Damien Saucez |
2021-08-31
|
14 | Damien Saucez | Uploaded new revision |
2021-07-29
|
13 | Alvaro Retana | Shepherding AD changed to Alvaro Retana |
2021-07-29
|
13 | Alvaro Retana | Notification list changed to aretana.ietf@gmail.com |
2021-02-11
|
13 | (System) | RFC Editor state changed to MISSREF from EDIT |
2021-02-11
|
13 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-11-08
|
13 | Suresh Krishnan | Shepherding AD changed to Suresh Krishnan |
2015-10-14
|
13 | (System) | Notify list changed from ggx@gigix.net, lisp-chairs@ietf.org to (None) |
2015-04-24
|
13 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-04-24
|
13 | (System) | RFC Editor state changed to MISSREF |
2015-04-24
|
13 | (System) | Announcement was received by RFC Editor |
2015-04-23
|
13 | (System) | IANA Action state changed to No IC from In Progress |
2015-04-23
|
13 | (System) | IANA Action state changed to In Progress |
2015-04-23
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-04-23
|
13 | Amy Vezza | IESG has approved the document |
2015-04-23
|
13 | Amy Vezza | Closed "Approve" ballot |
2015-04-23
|
13 | Amy Vezza | IESG state changed to Approved-announcement to be sent from IESG Evaluation::External Party |
2015-04-23
|
13 | Brian Haberman | Ballot approval text was generated |
2015-04-23
|
13 | Brian Haberman | Ballot writeup was changed |
2015-04-15
|
13 | Brian Haberman | Waiting on IANA. |
2015-04-15
|
13 | Brian Haberman | IESG state changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup |
2015-04-14
|
13 | Kathleen Moriarty | [Ballot comment] Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide … [Ballot comment] Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide the background needed for an introduction draft. While the edits in the security section help enough that I'll let it go, the other problems were not highlighted here and will rely on subsequent drafts elaborating on the threats and security considerations besides DoS. I haven't read the threats draft yet, so hopefully that covers the full set. Thanks. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html |
2015-04-14
|
13 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2015-04-14
|
13 | Alia Atlas | [Ballot comment] Thanks for addressing my discuss and comments. I support Adrian's discuss. In a similar vein: In Sec 3.2: Please either remove the claim … [Ballot comment] Thanks for addressing my discuss and comments. I support Adrian's discuss. In a similar vein: In Sec 3.2: Please either remove the claim of "Such LISP capable routers, in most cases, only require a software upgrade." or explain how you can justify the need to add and remove new encapsulations and handle the various flag triggers and caching at line rate. There is no need for such marketing in this document. 1) Sec 1, second paragraph: "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses." What does "typically" mean? As far as I'm aware, they are syntactically identical. This is reiterated in Sec 3.2; are you just trying to preserve the point of architectural freedom? I've found the third instance of insisting that the EID or RLOC now is only "typically" an IPv4 or IPv6 address. Please lose "typically". Minorly, the , before both should be a ;. 2) top paragraph of p.4: "The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP is completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System." Instead of "LISP is completely deployed" to "LISP were to be completely deployed" - making it subjunctive. 3) Last paragraph in Sec 1: "This document describes the LISP architecture, its main operational mechanisms as its design rationale." I think you mean "This document describes the LISP architecture and its main operational mechanisms as well as its design rationale." 4) In Sec 3.1, second paragraph: "Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale." I assume that you mean "topologically meaningful addresses" instead of "identity meaningful addresses". |
2015-04-14
|
13 | Alia Atlas | [Ballot Position Update] Position for Alia Atlas has been changed to No Objection from Discuss |
2015-04-08
|
13 | Alexey Melnikov | Request for Telechat review by GENART Completed: Ready. Reviewer: Alexey Melnikov. |
2015-04-02
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-04-02
|
13 | Albert Cabellos-Aparicio | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-04-02
|
13 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-13.txt |
2015-03-27
|
12 | Brian Haberman | Shepherding AD changed to Brian Haberman |
2015-03-25
|
12 | Amy Vezza | Shepherding AD changed to Deborah Brungard |
2015-03-05
|
12 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2015-03-05
|
12 | Cindy Morgan | Changed consensus to Yes from Unknown |
2015-03-05
|
12 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-03-05
|
12 | Alia Atlas | [Ballot discuss] I support Adrian's discuss. In a similar vein: In Sec 3.2: Please either remove the claim of "Such LISP capable routers, in most … [Ballot discuss] I support Adrian's discuss. In a similar vein: In Sec 3.2: Please either remove the claim of "Such LISP capable routers, in most cases, only require a software upgrade." or explain how you can justify the need to add and remove new encapsulations and handle the various flag triggers and caching at line rate. There is no need for such marketing in this document. |
2015-03-05
|
12 | Alia Atlas | [Ballot comment] 1) Sec 1, second paragraph: "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically … [Ballot comment] 1) Sec 1, second paragraph: "LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses." What does "typically" mean? As far as I'm aware, they are syntactically identical. This is reiterated in Sec 3.2; are you just trying to preserve the point of architectural freedom? I've found the third instance of insisting that the EID or RLOC now is only "typically" an IPv4 or IPv6 address. Please lose "typically". Minorly, the , before both should be a ;. 2) top paragraph of p.4: "The initial motivation in the LISP effort is to be found in the routing scalability problem [RFC4984], where, if LISP is completely deployed, the Internet core is populated with RLOCs while Traffic Engineering mechanisms are pushed to the Mapping System." Instead of "LISP is completely deployed" to "LISP were to be completely deployed" - making it subjunctive. 3) Last paragraph in Sec 1: "This document describes the LISP architecture, its main operational mechanisms as its design rationale." I think you mean "This document describes the LISP architecture and its main operational mechanisms as well as its design rationale." 4) In Sec 3.1, second paragraph: "Locator/Identifier split: By decoupling the overloaded semantics of the current IP addresses the Internet core can be assigned identity meaningful addresses and hence, can use aggregation to scale." I assume that you mean "topologically meaningful addresses" instead of "identity meaningful addresses". |
2015-03-05
|
12 | Alia Atlas | [Ballot Position Update] New position, Discuss, has been recorded for Alia Atlas |
2015-03-05
|
12 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-03-05
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-03-05
|
12 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-03-04
|
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-03-04
|
12 | Richard Barnes | [Ballot comment] I would also find this document much improved if the authors could address Adrian's comments, as well as those in Radia's SECDIR review. |
2015-03-04
|
12 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2015-03-04
|
12 | Kathleen Moriarty | [Ballot comment] Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide … [Ballot comment] Please do look at the other suggestions from the review as they should help clarify a few points in the draft and provide the background needed for an introduction draft. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html |
2015-03-04
|
12 | Kathleen Moriarty | Ballot comment text updated for Kathleen Moriarty |
2015-03-04
|
12 | Kathleen Moriarty | [Ballot discuss] It appears the SecDir review didn't make it to LISP list for some reason. There is one important security request from Radia's review … [Ballot discuss] It appears the SecDir review didn't make it to LISP list for some reason. There is one important security request from Radia's review and many other good suggestions. https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html Expanding the Security Considerations section would be helpful, here is the background on the request: There is a security considerations section, which focuses on a class of denial of service attacks. There are presumably security considerations sections in the other documents, including one that focuses entirely on security, so it is not necessary that all security issues be brought up here. That said, I think that if you were to write an "introduction to security considerations", there are more important ones than the DoS threat. in particular, as a routing protocol care must be taken to make sure a bad actor cannot attract someone else's traffic with mechanisms like those we are trying to address with BGP security. Much of the routing information is maintained in a database "like DNS". If it *were* DNS, DNSSEC could be used to address the integrity issues. If it is home grown, some equivalent mechanism will be necessary. Why not use DNS? |
2015-03-04
|
12 | Kathleen Moriarty | [Ballot comment] Please do look at the other suggestions from the review: https://www.ietf.org/mail-archive/web/secdir/current/msg05415.html |
2015-03-04
|
12 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2015-03-04
|
12 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2015-03-03
|
12 | Spencer Dawkins | [Ballot comment] I'm a Yes because this draft is helpful to the largely uninitiated (that would include me), but I was consistently encountering questions that … [Ballot comment] I'm a Yes because this draft is helpful to the largely uninitiated (that would include me), but I was consistently encountering questions that Adrian's Discuss and Comments answered, so I'd encourage you to work through his Comments, as well as his Discuss. Beyond that: In this text: 3.3.1. LISP Encapsulation ITRs encapsulate data packets towards ETRs. LISP data packets are encapsulated using UDP (port 4341), the source port is usually selected by the ITR using a 5-tuple hash of the inner header (so to be consistent in case of multi-path solutions such as ECMP [RFC2992]) and ignored on reception. would you ever use "virtual xTRs" with the same outermost IP addresses? If not, fine, but if so, would you need to use different destination ports to disambiguate them? Or does the Instance ID provide enough isolation to meet this need? I ask because adding virtual hosts to HTTP was a drag, so best for me to ask early! Further in the same paragraph, in this text: A particularity of LISP is that UDP packets should include a zero checksum [RFC6935] [RFC6936] that it is not verified in reception, LISP also supports non-zero checksums that may be verified. This decision was made because the typical transport protocols used by the applications already include a checksum, by neglecting the additional UDP encapsulation checksum xTRs can forward packets more efficiently. I'm wobbling between "should include a zero checksum" and "also supports non-zero checksums". Is that text saying something like this? LISP data packets are often encapsulated in UDP packets that include a zero checksum [RFC6935] [RFC6936] that is not verified when it is received, because LISP data packets typically include an inner transport protocol header with a non-zero checksum. By omitting the additional outer UDP encapsulation checksum, xTRs can forward packets more efficiently. If LISP data packets are encapsulated in UDP packets with non-zero checksums, the outer UDP checksums are verified when the UDP packets are received, as part of normal UDP processing. |
2015-03-03
|
12 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2015-03-03
|
12 | Adrian Farrel | [Ballot discuss] Thank you for this document. It is really helpful to have a clear introduction to LISP, and I appreciate the hard work that … [Ballot discuss] Thank you for this document. It is really helpful to have a clear introduction to LISP, and I appreciate the hard work that has gone into producing this text. I have a small Discuss that is easily fixed. The essence is that you should limit this document to a description of LISP and not try to use it to bash other solutions. In Section 4.2 On the contrary BGP is a push architecture, where the required network state is pushed by means of BGP UPDATE messages to BGP speakers. You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode protocol. (I won't say to you that LISP is push mode because a Map-Reply pushes the mapping information from the map server to the client :-) So, my advice is to describe LISP in this document and to not make comments about other systems. It isn't a beauty contest and it isn't wise to try to say "my system is better/different from yours". The solution is to just remove this sentence. Similarly in 7.1 BGP is the standard protocol to implement inter-domain routing. With BGP, routing information are propagated along the network and each autonomous system can implement its own routing policy that will influence the way routing information are propagated. The direct consequence is that an autonomous system cannot precisely control the way the traffic will enter the network. As opposed to BGP, a LISP site can strictly impose via which ETRs the traffic must enter the the LISP site network even though the path followed to reach the ETR is not under the control of the LISP site. Let's not get into the "BGP this, BGP that" debate. Just remove the first paragraph and the first four words of the second paragraph. That way you avoid all contention and write a document about LISP. |
2015-03-03
|
12 | Adrian Farrel | [Ballot comment] I have a few questions and editorial nits I hope you will pick up as additional polish. Some of the nits come from … [Ballot comment] I have a few questions and editorial nits I hope you will pick up as additional polish. Some of the nits come from Deborah's review as AD in-training --- Section 1 I'm really not comfortable with your text... "Indeed and as pointed out by the unpublished Internet Draft by Noel Chiappa [Chiappa]" This isn't a stable reference and I don't think you need it. You could either rely on the later reference to RFC 4984, reference RFC 6830 itself, or take out the aside "and as... ... [Chiappa]" --- Section 1 has LISP creates two separate namespaces, EIDs (End-host IDentifiers) and RLOCs (Routing LOCators), both are typically syntactically identical to the current IPv4 and IPv6 addresses. The "typically" here opens a bit of door. RFC 6830 explains this in the definitions of EID, but seems to be clear that an RLOC is an IP address. If you are opening up the RLOC to be something other than an IP address (a MAC address or even something else?) then how do you deal with: - lack of ICMP - non-uniqueness Possibly you can say that this is "not my problem" since the problem would already exist in the routing system that handles the non-IP addresses. But maybe, for an introduction to the topic this is over- reaching towards the many potential applications rather than the basic explanation of the architecture? But in your own definitions in Section 2, you have Endpoint IDentifier (EID): EIDs are IPv4 or IPv6 addresses used to uniquely identify nodes irrespective of their topological location and are typically routed intra-domain. Routing LOcator (RLOC): RLOCs are IPv4 or IPv6 addresses assigned topologically to network attachment points and typically routed inter-domain. Neither of which offers any possiblitity to vary "always" into "typically". The again, 3.2 has... EIDs are typically -but not limited to- IPv4 or IPv6 addresses ...and... With LISP, the core uses RLOCs, an RLOC is typically -but not limited to- an IPv4 or IPv6 address Some concistency is needed! In 3.4.1 you finally get there... Typical mappings in LISP bind EIDs in the form of IP prefixes with a set of RLOCs, also in the form of IPs. IPv4 and IPv6 addresses are encoded using the appropriate Address Family Identifier (AFI) [RFC3232]. However LISP can also support more general address encoding by means of the ongoing effort around the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf]. Why don't you talk about everything in terms of IP adresses and then add a section somewhere near the end to talk about LCAF? --- Section 1 introduces "overlay" and "underlay". I think that a certain class of network engineer understands these concepts really well. And, in my experience, another class has no idea what you are talking about! This would probably show very easily on a simple diagram showing the overlay and underlay networks. But perhaps the summary in the Introduction is launching in a bit deep nd fast? This is probably the hardest part of the document to write: how do you summarise what you haven't yet talked about? There are some bits, however, that really need work. For example... o EIDs have meaning only in the overlay network unless they are leaked into the underlay network. The overlay is the encapsulation relationship between LISP-capable routers. Furthermore EIDs are not assigned from the reserved address blocks. So they have meaning only in one place, unless they have meaning in more than one place? :-) And what is a "resrved address block"? --- Section 3.2 With LISP, LISP sites (edge) and the core of the Internet are interconnected by means of LISP-capable routers (e.g., border routers) using tunnels. I don't think this is right. It is true that LISP sites and the core of the Internet are interconnected by means of LISP-capable routers But the tunnels connect those border routers. So you probably need... LISP sites (at the edge of the Internet) are connected to the core of the Internet by means of LISP-capable routers (e.g., border routers). LISP sites are connected across the core of the Internet using tunnels between the LISP-capable routers. --- Section 3.2 OLD A typically distributed database, called the Mapping System, stores mappings between EIDs and RLOCs. NEW A database which is typically distributed, called the Mapping System, stores mappings between EIDs and RLOCs. --- 3.2 Such LISP capable routers, in most cases, only require a software upgrade. That's a little disconcerting. Can you add to "in most cases"? --- 4.1 Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon expiration of the TTL the ITR has to refresh the mapping by sending a new Map-Request. Typical values for TTL defined by LISP are 24 hours. Presumably it doesn't *have to*. It can choose to delete it and not refresh it. Maybe this should be worded as MUST NOT use after the expiration of the TTL. --- Section 5 says The separation between locators and identifiers in LISP was initially proposed for traffic engineering purpose where LISP sites can change their attachment points to the Internet (i.e., RLOCs) without impacting endpoints or the Internet core. RFC 6830 says Creation of LISP was initially motivated by discussions during the IAB-sponsored Routing and Addressing Workshop held in Amsterdam in October 2006 (see [RFC4984]). RFC 4984 says The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. I conclude that Section 5 here is somewhat wrong. --- Section 7.1 "the possibility for a site to issue a different mapping for each remote site, implementing so precise routing policies." Suggest "the possibility for a site to support a different mapping policy for each remote site." --- I think some examination of the classification of normative and informative references would be useful. For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think that is fine because it is where to go for a definition of LISP+ALT. But 3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt] which turns out to be Informative. --- Appendix A "The LISP system.." Haven't seen a "LISP system" defined. Suggest "The LISP architecture.." --- Appendix A "A small group of like-minded personnel from various scattered locations within Cisco, spontaneously formed immediately after that workshop, to work on an idea that came out of informal discussions at the workshop and on various mailing lists." Suggest deleting this sentence (unless you want this to look like a Cisco-only initiative). |
2015-03-03
|
12 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel |
2015-02-25
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2015-02-25
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Alexey Melnikov |
2015-02-17
|
12 | Albert Cabellos-Aparicio | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-02-17
|
12 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-12.txt |
2015-02-17
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: David Black. |
2015-02-13
|
11 | Alexey Melnikov | Request for Last Call review by GENART Completed: Ready. Reviewer: Alexey Melnikov. |
2015-02-10
|
11 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2015-02-10
|
11 | Brian Haberman | Placed on agenda for telechat - 2015-03-05 |
2015-02-10
|
11 | Brian Haberman | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-02-10
|
11 | Brian Haberman | Ballot has been issued |
2015-02-10
|
11 | Brian Haberman | [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman |
2015-02-10
|
11 | Brian Haberman | Created "Approve" ballot |
2015-02-09
|
11 | Albert Cabellos-Aparicio | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-02-09
|
11 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-11.txt |
2015-02-09
|
10 | Brian Haberman | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2015-02-09
|
10 | Brian Haberman | Ballot writeup was changed |
2015-02-04
|
10 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2015-01-31
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Black |
2015-01-31
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to David Black |
2015-01-29
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Radia Perlman. |
2015-01-27
|
10 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-01-27
|
10 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-lisp-introduction-10, which is currently in Last Call, and has the following comments: We understand that, upon approval of this … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-lisp-introduction-10, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2015-01-22
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2015-01-22
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Alexey Melnikov |
2015-01-22
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2015-01-22
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Radia Perlman |
2015-01-21
|
10 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2015-01-21
|
10 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (An Architectural Introduction to the … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (An Architectural Introduction to the Locator/ID Separation Protocol (LISP)) to Informational RFC The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'An Architectural Introduction to the Locator/ID Separation Protocol (LISP)' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-02-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the architecture of the Locator/ID Separation Protocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes, more details can be found in RFC6830, the protocol specification. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/ballot/ No IPR declarations have been submitted directly on this I-D. |
2015-01-21
|
10 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2015-01-21
|
10 | Brian Haberman | Last call was requested |
2015-01-21
|
10 | Brian Haberman | Last call announcement was generated |
2015-01-21
|
10 | Brian Haberman | Ballot approval text was generated |
2015-01-21
|
10 | Brian Haberman | Ballot writeup was generated |
2015-01-21
|
10 | Brian Haberman | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2015-01-21
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-01-21
|
10 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-10.txt |
2015-01-14
|
09 | Brian Haberman | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2015-01-05
|
09 | Brian Haberman | IESG state changed to AD Evaluation from Publication Requested |
2015-01-05
|
09 | Brian Haberman | Intended Status changed to Informational |
2015-01-05
|
09 | Brian Haberman | IESG process started in state Publication Requested |
2015-01-05
|
09 | (System) | Earlier history may be found in the Comment Log for /doc/draft-chiappa-lisp-introduction/ |
2015-01-05
|
09 | Brian Haberman | Working group state set to Submitted to IESG for Publication |
2015-01-05
|
09 | Brian Haberman | Shepherding AD changed to Brian Haberman |
2014-12-31
|
09 | Luigi Iannone | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2014-12-31
|
09 | Luigi Iannone | Changed document writeup |
2014-11-14
|
09 | Luigi Iannone | Notification list changed to "Luigi Iannone" <ggx@gigix.net> |
2014-11-14
|
09 | Luigi Iannone | Document shepherd changed to Luigi Iannone |
2014-11-14
|
09 | Luigi Iannone | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2014-11-13
|
09 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-09.txt |
2014-11-12
|
08 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-08.txt |
2014-10-25
|
07 | Luigi Iannone | IETF WG state changed to In WG Last Call from WG Document |
2014-10-24
|
07 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-07.txt |
2014-10-24
|
07 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-07.txt |
2014-10-23
|
06 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-06.txt |
2014-09-22
|
05 | Albert Cabellos-Aparicio | New version available: draft-ietf-lisp-introduction-05.txt |
2014-07-16
|
04 | Naveen Khan | New revision available |
2013-10-21
|
03 | J. Chiappa | New version available: draft-ietf-lisp-introduction-03.txt |
2013-10-01
|
02 | J. Chiappa | New version available: draft-ietf-lisp-introduction-02.txt |
2013-07-15
|
01 | J. Chiappa | New version available: draft-ietf-lisp-introduction-01.txt |
2012-10-15
|
00 | J. Chiappa | New version available: draft-ietf-lisp-introduction-00.txt |