Re: [lisp] [Ila] LISP for ILA
The cost per EID-record is 12 bytes plus size of the EID address and for an RLOC-record is 12 bytes plus size of the RLOC address. This assumes you use AFI=2. Not what the draft is proposing. Dino # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # | Record TTL | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # | Locator Count | EID mask-len | ACT |A|I| Reserved| # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # |SigCnt | Map Version Number |EID-AFI| # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # | EID-prefix ... | # +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # /|Priority |Weight | M Priority | M Weight| # L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # o |Unused Flags |L|p|R| Loc-AFI | # c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ # \| Locator | #+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > On Mar 5, 2018, at 6:23 PM, Tom Herbert wrote: > > On Mon, Mar 5, 2018 at 5:00 PM, Dino Farinacci wrote: >>> Looking at the map-reply message format, I am concerned about its >>> size. By my count, it's 40 bytes to provide one record with one >>> locator where record and locator are 8 bytes. If we need to scale a >>> system to billions of nodes this overhead could be an issue even if >>> it's the control plane. Is there any plan to have a compressed version >>> of this. For instance ,if there is only one RLOC returned wouldn't the >>> priorities and weights be useless? >> >> My comment about this spec is that you really don’t need a LCAF format to >> format the addresses. You can use AFI=2 and use IPv6 format. That will >> reduce the size. >> >> But if you start compressing out fields, reality will set in and new >> features will be added and you’ll be back where we started. You want to >> multi-home, don’t you? > > There are a bunch of reserved and unused flag bits in the message > format. One could define flag-fields to make the messages extensible > and variable length (without resorting to TLVs!). > > Tom ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [Ila] LISP for ILA
On Mon, Mar 5, 2018 at 5:00 PM, Dino Farinacci wrote: >> Looking at the map-reply message format, I am concerned about its >> size. By my count, it's 40 bytes to provide one record with one >> locator where record and locator are 8 bytes. If we need to scale a >> system to billions of nodes this overhead could be an issue even if >> it's the control plane. Is there any plan to have a compressed version >> of this. For instance ,if there is only one RLOC returned wouldn't the >> priorities and weights be useless? > > My comment about this spec is that you really don’t need a LCAF format to > format the addresses. You can use AFI=2 and use IPv6 format. That will reduce > the size. > > But if you start compressing out fields, reality will set in and new features > will be added and you’ll be back where we started. You want to multi-home, > don’t you? There are a bunch of reserved and unused flag bits in the message format. One could define flag-fields to make the messages extensible and variable length (without resorting to TLVs!). Tom ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [Ila] LISP for ILA
> Looking at the map-reply message format, I am concerned about its > size. By my count, it's 40 bytes to provide one record with one > locator where record and locator are 8 bytes. If we need to scale a > system to billions of nodes this overhead could be an issue even if > it's the control plane. Is there any plan to have a compressed version > of this. For instance ,if there is only one RLOC returned wouldn't the > priorities and weights be useless? My comment about this spec is that you really don’t need a LCAF format to format the addresses. You can use AFI=2 and use IPv6 format. That will reduce the size. But if you start compressing out fields, reality will set in and new features will be added and you’ll be back where we started. You want to multi-home, don’t you? Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [Ila] LISP for ILA
Thanks for posting the draft! Overall, I think the approach straightforward, and it's very nice that there is no change required to the ILA architecture. I have some concerns about the LISP control plane in terms of DOSability and scalability. Btw, LISP is not in Linux kernel because of concerns about DOSability, so there was some prior discussion on this topic in related mailing lists, >From the draft: "When an ILA-N has to send traffic towards a remote Identifier for which it does not have the associated Locator, it has to obtain it first from a MS." This is not actually true. The forwarding cache in the ILA-N is a routing optimization, if there is no entry on the cache then the packet is forwarded. If it needs to be transformed then that will be done by an ILA-R in the path. Until the cache is populated the routing might be sub-optimal but packets still flow. This is reflected below in: "While the mapping is being resolved via the Map-Request/ Map-Reply process, the ILA-N can send the data packets to the underlay using the SIR address." I think it should be assumed in ILA that not queuing packets and not dropping packets because of resolution are requirements (too much latency hit). If the map request is sent and the packet is forwarded, that means that a packet received at the ILA-N can generate two packets to be forwarded in the network. An obvious DOS attack is for a host to send random to destinations in the network to try to generate cache misses. Section 8.2 discusses this, but the solution to implement heavy hitters counters is not detailed. It would be nice to see more detail how this would work and how it will mitigate the DOS attack. In ILAMP, a redirect method is defined. On a chache miss the packet is forwarded and no other action is taken. If an ILA-R does transformation it may send back a mapping redirect informing the ILA-N of a transformation. The redirects must be completely secure (one reason I'm partial to TCP) and are only sent to inform an ILA-N about a positive response. To a large extent this neutralizes the above random address DOS attack. There are other means of attack on the cache, but the exposure is narrowed I believe. "LISP as defined in [I-D.ietf-lisp-rfc6833bis] runs over a UDP transport, however the exact same signaling can be used over a TCP transport without affecting the protocol operation." What is the status of TCP support? I believe the trend in datacenter control protocols is towards TCP and even RPC. Integrated security, congestion control, authentication, and tooling are strong points in favor of TCP. Is it reasonable to say that TCP is the preferred protocol? Can the LISP message easily be converted to RPC (REST, Thrift, GRPC, ...? Looking at the map-reply message format, I am concerned about its size. By my count, it's 40 bytes to provide one record with one locator where record and locator are 8 bytes. If we need to scale a system to billions of nodes this overhead could be an issue even if it's the control plane. Is there any plan to have a compressed version of this. For instance ,if there is only one RLOC returned wouldn't the priorities and weights be useless? Thanks, Tom On Sat, Mar 3, 2018 at 10:39 PM, Alberto Rodriguez Natal (natal) wrote: > Hi all, > > > > We have just posted a draft describing how to use the LISP control-plane > with the ILA data-plane. The document is in an early stage and any feedback > is welcome. We hope to be presenting this at London. > > > > https://tools.ietf.org/html/draft-rodrigueznatal-ila-lisp-00 > > > > Thanks, > > Alberto > > > ___ > ila mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/ila > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] I-D Action: draft-ietf-lisp-yang-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP YANG Model Authors : Vina Ermagan Alberto Rodriguez-Natal Florin Coras Carl Moberg Reshad Rahman Albert Cabellos-Aparicio Fabio Maino Filename: draft-ietf-lisp-yang-07.txt Pages : 58 Date: 2018-03-05 Abstract: This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-yang-07 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-yang-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-yang-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] I-D Action: draft-ietf-lisp-rfc6830bis-11.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : The Locator/ID Separation Protocol (LISP) Authors : Dino Farinacci Vince Fuller Dave Meyer Darrel Lewis Albert Cabellos Filename: draft-ietf-lisp-rfc6830bis-11.txt Pages : 43 Date: 2018-03-05 Abstract: This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. LISP requires no change to either host protocol stacks or to underlay routers and offers Traffic Engineering, multihoming and mobility, among other features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-11 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt
Hi I'll post a new version without such sections shortly. I volunteer to help writing the OAM document. Albert On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci wrote: > >> On 5 Mar 2018, at 19:06, Dino Farinacci wrote: > >> > >>> Hi all > >>> > >>> This document should address all the comments except this one: > >>> > >>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement > Considerations), 18 (Traceroute Consideration) to a new OAM document > >>> > >>> The authors would like to have a better understanding of where this > text will go. > >> > >> Right, we concluded to not remove the valuable text. > > > > Nobody wants to lose valuable text. > > Glad you feel that way. > > > > >> A lot of time and thought went into writing it and we didn’t want to > lose it. There was no where that was agreed upon to put it. > > > > That is not accurate. There was clear indication to move it to a new OAM > document, without any change in the text. > > Purpose was to have just a different placeholder that make more sense. > > This is an half an hour task. > > But there was also concerns about slowing the process down. And the > co-authors (Albert and I) don’t think it should move from RFC6833. > > So there isn’t concensus. And I don’t believe it is even rough concensus. > > > > >> > >> So since we felt there was no concensus on Sections 16-18, we didn’t > make any change. > > > > Again not accurate, please spend half an hour to create the OAM document. > > If you do not have time we can appoint other editors for the task. > Authorship will be anyway preserved. > > > Section 16 is “Mobility Considerations” that discusses various forms of > how EIDs can change RLOCs. And it sets up for different designs that are > already documented in various documents. But Mobility certainly shouldn’t > go in an OAM document. > > Section 17 discusses where xTRs (data-plane boxes) should reside in the > network. And sets up for a more detail discussion which is in the > Deployment RFC. > > Section 18 is “Traceroute Considerations”, this arguably can go into an > OAM document. But it would be 3 pages. And then one would argue there are > other OAM mechanisms spread across LISP documents that could go in an OAM > document. > > This will not take 1/2 hour. > > And I’m finding it hard to see the value in doing all this busy work. We > have already accomplished separating data-plane text from control-plane > text. We achieved that goal from the charter. > > Dino > > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt
>> On 5 Mar 2018, at 19:06, Dino Farinacci wrote: >> >>> Hi all >>> >>> This document should address all the comments except this one: >>> >>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement >>> Considerations), 18 (Traceroute Consideration) to a new OAM document >>> >>> The authors would like to have a better understanding of where this text >>> will go. >> >> Right, we concluded to not remove the valuable text. > > Nobody wants to lose valuable text. Glad you feel that way. > >> A lot of time and thought went into writing it and we didn’t want to lose >> it. There was no where that was agreed upon to put it. > > That is not accurate. There was clear indication to move it to a new OAM > document, without any change in the text. > Purpose was to have just a different placeholder that make more sense. > This is an half an hour task. But there was also concerns about slowing the process down. And the co-authors (Albert and I) don’t think it should move from RFC6833. So there isn’t concensus. And I don’t believe it is even rough concensus. > >> >> So since we felt there was no concensus on Sections 16-18, we didn’t make >> any change. > > Again not accurate, please spend half an hour to create the OAM document. > If you do not have time we can appoint other editors for the task. Authorship > will be anyway preserved. Section 16 is “Mobility Considerations” that discusses various forms of how EIDs can change RLOCs. And it sets up for different designs that are already documented in various documents. But Mobility certainly shouldn’t go in an OAM document. Section 17 discusses where xTRs (data-plane boxes) should reside in the network. And sets up for a more detail discussion which is in the Deployment RFC. Section 18 is “Traceroute Considerations”, this arguably can go into an OAM document. But it would be 3 pages. And then one would argue there are other OAM mechanisms spread across LISP documents that could go in an OAM document. This will not take 1/2 hour. And I’m finding it hard to see the value in doing all this busy work. We have already accomplished separating data-plane text from control-plane text. We achieved that goal from the charter. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt
> On 5 Mar 2018, at 19:06, Dino Farinacci wrote: > >> Hi all >> >> This document should address all the comments except this one: >> >> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement >> Considerations), 18 (Traceroute Consideration) to a new OAM document >> >> The authors would like to have a better understanding of where this text >> will go. > > Right, we concluded to not remove the valuable text. Nobody wants to lose valuable text. > A lot of time and thought went into writing it and we didn’t want to lose it. > There was no where that was agreed upon to put it. That is not accurate. There was clear indication to move it to a new OAM document, without any change in the text. Purpose was to have just a different placeholder that make more sense. This is an half an hour task. > > So since we felt there was no concensus on Sections 16-18, we didn’t make any > change. Again not accurate, please spend half an hour to create the OAM document. If you do not have time we can appoint other editors for the task. Authorship will be anyway preserved. Thanks Luigi > > Dino > >> >> If we adress this by today I can submit a new version (before the cut-off) >> taking this comment into account. >> >> Thanks! >> >> Albert >> >> On Mon, Mar 5, 2018 at 10:44 AM, Luigi Iannone wrote: >> Hi Albert, Dino, >> >> this version of the document doesn’t not yet completely respect the >> discussions of the last months. >> >> Do you plan another version before London? >> >> Thanks >> >> Luigi >> >> >>> On 5 Mar 2018, at 00:51, internet-dra...@ietf.org wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Locator/ID Separation Protocol WG of the >>> IETF. >>> >>> Title : The Locator/ID Separation Protocol (LISP) >>> Authors : Dino Farinacci >>> Vince Fuller >>> Dave Meyer >>> Darrel Lewis >>> Albert Cabellos >>> Filename: draft-ietf-lisp-rfc6830bis-10.txt >>> Pages : 50 >>> Date: 2018-03-04 >>> >>> Abstract: >>> This document describes the data-plane protocol for the Locator/ID >>> Separation Protocol (LISP). LISP defines two namespaces, End-point >>> Identifiers (EIDs) that identify end-hosts and Routing Locators >>> (RLOCs) that identify network attachment points. With this, LISP >>> effectively separates control from data, and allows routers to create >>> overlay networks. LISP-capable routers exchange encapsulated packets >>> according to EID-to-RLOC mappings stored in a local map-cache. >>> >>> LISP requires no change to either host protocol stacks or to underlay >>> routers and offers Traffic Engineering, multihoming and mobility, >>> among other features. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-10 >>> https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-10 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-10 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> ___ >>> I-D-Announce mailing list >>> i-d-annou...@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> ___ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp >> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] I-D Action: draft-ietf-lisp-gpe-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol WG of the IETF. Title : LISP Generic Protocol Extension Authors : Darrel Lewis John Lemon Puneet Agarwal Larry Kreeger Paul Quinn Michael Smith Navindra Yadav Fabio Maino Filename: draft-ietf-lisp-gpe-01.txt Pages : 8 Date: 2018-03-05 Abstract: This draft describes extending the Locator/ID Separation Protocol (LISP), via changes to the LISP header, to support multi-protocol encapsulation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lisp-gpe-01 https://datatracker.ietf.org/doc/html/draft-ietf-lisp-gpe-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-gpe-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt
> Hi all > > This document should address all the comments except this one: > > G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement > Considerations), 18 (Traceroute Consideration) to a new OAM document > > The authors would like to have a better understanding of where this text will > go. Right, we concluded to not remove the valuable text. A lot of time and thought went into writing it and we didn’t want to lose it. There was no where that was agreed upon to put it. So since we felt there was no concensus on Sections 16-18, we didn’t make any change. Dino > > If we adress this by today I can submit a new version (before the cut-off) > taking this comment into account. > > Thanks! > > Albert > > On Mon, Mar 5, 2018 at 10:44 AM, Luigi Iannone wrote: > Hi Albert, Dino, > > this version of the document doesn’t not yet completely respect the > discussions of the last months. > > Do you plan another version before London? > > Thanks > > Luigi > > > > On 5 Mar 2018, at 00:51, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Locator/ID Separation Protocol WG of the > > IETF. > > > >Title : The Locator/ID Separation Protocol (LISP) > >Authors : Dino Farinacci > > Vince Fuller > > Dave Meyer > > Darrel Lewis > > Albert Cabellos > > Filename: draft-ietf-lisp-rfc6830bis-10.txt > > Pages : 50 > > Date: 2018-03-04 > > > > Abstract: > > This document describes the data-plane protocol for the Locator/ID > > Separation Protocol (LISP). LISP defines two namespaces, End-point > > Identifiers (EIDs) that identify end-hosts and Routing Locators > > (RLOCs) that identify network attachment points. With this, LISP > > effectively separates control from data, and allows routers to create > > overlay networks. LISP-capable routers exchange encapsulated packets > > according to EID-to-RLOC mappings stored in a local map-cache. > > > > LISP requires no change to either host protocol stacks or to underlay > > routers and offers Traffic Engineering, multihoming and mobility, > > among other features. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-10 > > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-10 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-10 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > ___ > > I-D-Announce mailing list > > i-d-annou...@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt
Hi all This document should address all the comments except this one: G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement Considerations), 18 (Traceroute Consideration) to a new OAM document The authors would like to have a better understanding of where this text will go. If we adress this by today I can submit a new version (before the cut-off) taking this comment into account. Thanks! Albert On Mon, Mar 5, 2018 at 10:44 AM, Luigi Iannone wrote: > Hi Albert, Dino, > > this version of the document doesn’t not yet completely respect the > discussions of the last months. > > Do you plan another version before London? > > Thanks > > Luigi > > > > On 5 Mar 2018, at 00:51, internet-dra...@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Locator/ID Separation Protocol WG of > the IETF. > > > >Title : The Locator/ID Separation Protocol (LISP) > >Authors : Dino Farinacci > > Vince Fuller > > Dave Meyer > > Darrel Lewis > > Albert Cabellos > > Filename: draft-ietf-lisp-rfc6830bis-10.txt > > Pages : 50 > > Date: 2018-03-04 > > > > Abstract: > > This document describes the data-plane protocol for the Locator/ID > > Separation Protocol (LISP). LISP defines two namespaces, End-point > > Identifiers (EIDs) that identify end-hosts and Routing Locators > > (RLOCs) that identify network attachment points. With this, LISP > > effectively separates control from data, and allows routers to create > > overlay networks. LISP-capable routers exchange encapsulated packets > > according to EID-to-RLOC mappings stored in a local map-cache. > > > > LISP requires no change to either host protocol stacks or to underlay > > routers and offers Traffic Engineering, multihoming and mobility, > > among other features. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-10 > > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-10 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-10 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > ___ > > I-D-Announce mailing list > > i-d-annou...@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > ___ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt
Hi Albert, Dino, this version of the document doesn’t not yet completely respect the discussions of the last months. Do you plan another version before London? Thanks Luigi > On 5 Mar 2018, at 00:51, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Locator/ID Separation Protocol WG of the > IETF. > >Title : The Locator/ID Separation Protocol (LISP) >Authors : Dino Farinacci > Vince Fuller > Dave Meyer > Darrel Lewis > Albert Cabellos > Filename: draft-ietf-lisp-rfc6830bis-10.txt > Pages : 50 > Date: 2018-03-04 > > Abstract: > This document describes the data-plane protocol for the Locator/ID > Separation Protocol (LISP). LISP defines two namespaces, End-point > Identifiers (EIDs) that identify end-hosts and Routing Locators > (RLOCs) that identify network attachment points. With this, LISP > effectively separates control from data, and allows routers to create > overlay networks. LISP-capable routers exchange encapsulated packets > according to EID-to-RLOC mappings stored in a local map-cache. > > LISP requires no change to either host protocol stacks or to underlay > routers and offers Traffic Engineering, multihoming and mobility, > among other features. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-10 > https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
