Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
Hi, This WG Last call is now over and the chairs consider that there is sufficient support to move this document forward. We are looking for some help and we would appreciate if someone would volunteer to shepherd this document. Anybody interested? Thanks Ciao L. > On 3 Feb 2021, at 16:25, Luigi Iannone wrote: > > Hi All, > > The authors of draft-ietf-lisp-nexagon submitted the current version back in > October solving issues raised during SECDIR review. > No further comments have been raised and the authors consider the document > stable and ready for WG Last Call. > > This email open the usual two weeks Working Group Last Call, to end February > 17th, 2021. > > Please review this WG document and let the WG know if you agree that it is > ready to be handed over to the AD. > If you have objections, please state your reasons why, and explain what it > would take to address your concerns. > > NOTE: silence IS NOT consensus! > > Thanks > > Luigi & Joel ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
As an author, I support the document. I think it’s a very interesting use case, that shows how LISP can support a global geo-localization index infrastructure. A good example of how a fast, scalable lookup infrastructure can support, up to a certain extent, use cases that are typically considered the domain of peer-to-peer architectures. The document articulates the peculiarities of the use case, providing a guide on how to leverage the H3 geospatial indexing system on top of LISP. Fabio From: lisp on behalf of Luigi Iannone Date: Tuesday, February 23, 2021 at 11:17 PM To: "lisp@ietf.org list" Cc: "lisp-cha...@ietf.org" Subject: Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon Folks, while this document has gathered attention during face to face meetings, we received very few email in support of WG LC! In order to gather more consensus we prefer to extend the Last Call period by two weeks, to end by March 10th. Please speak up and state whether or not this document is ready to be published. Ciao Luigi & Joel On 3 Feb 2021, at 16:25, Luigi Iannone mailto:g...@gigix.net>> wrote: Hi All, The authors of draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review. No further comments have been raised and the authors consider the document stable and ready for WG Last Call. This email open the usual two weeks Working Group Last Call, to end February 17th, 2021. Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD. If you have objections, please state your reasons why, and explain what it would take to address your concerns. NOTE: silence IS NOT consensus! Thanks Luigi & Joel ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
I support the document. It’s the third time I have sent support for it during its course of development. Dino > On Feb 23, 2021, at 11:17 PM, Luigi Iannone wrote: > > Folks, > > while this document has gathered attention during face to face meetings, we > received very few email in support of WG LC! > > In order to gather more consensus we prefer to extend the Last Call period by > two weeks, to end by March 10th. > > Please speak up and state whether or not this document is ready to be > published. > > Ciao > > Luigi & Joel > > >> On 3 Feb 2021, at 16:25, Luigi Iannone wrote: >> >> Hi All, >> >> The authors of draft-ietf-lisp-nexagon submitted the current version back >> in October solving issues raised during SECDIR review. >> No further comments have been raised and the authors consider the document >> stable and ready for WG Last Call. >> >> This email open the usual two weeks Working Group Last Call, to end February >> 17th, 2021. >> >> Please review this WG document and let the WG know if you agree that it is >> ready to be handed over to the AD. >> If you have objections, please state your reasons why, and explain what it >> would take to address your concerns. >> >> NOTE: silence IS NOT consensus! >> >> Thanks >> >> Luigi & Joel > > ___ > 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] WG Last Call for draft-ietf-lisp-nexagon
Folks, while this document has gathered attention during face to face meetings, we received very few email in support of WG LC! In order to gather more consensus we prefer to extend the Last Call period by two weeks, to end by March 10th. Please speak up and state whether or not this document is ready to be published. Ciao Luigi & Joel > On 3 Feb 2021, at 16:25, Luigi Iannone wrote: > > Hi All, > > The authors of draft-ietf-lisp-nexagon submitted the current version back in > October solving issues raised during SECDIR review. > No further comments have been raised and the authors consider the document > stable and ready for WG Last Call. > > This email open the usual two weeks Working Group Last Call, to end February > 17th, 2021. > > Please review this WG document and let the WG know if you agree that it is > ready to be handed over to the AD. > If you have objections, please state your reasons why, and explain what it > would take to address your concerns. > > NOTE: silence IS NOT consensus! > > Thanks > > Luigi & Joel ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
Hi, As a co-author I believe this document is ready to hand it to the AD. Thanks, Jordi El 3/2/21 a les 16:25, Luigi Iannone ha escrit: Hi All, The authors of draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review. No further comments have been raised and the authors consider the document stable and ready for WG Last Call. This email open the usual two weeks Working Group Last Call, to end February 17th, 2021. Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD. If you have objections, please state your reasons why, and explain what it would take to address your concerns. NOTE: silence IS NOT consensus! Thanks Luigi & Joel ___ 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] WG Last Call for draft-ietf-lisp-nexagon
Thanks for your explanations. Now it is more clear to me. Best regards Albert On 8/2/21 13:44, Sharon Barkai wrote: Thanks Albert for pointing out these possible confusion points. Answering inline .. But first would like to clarify the exact subset of LISP we leverage for the Nexagon mobility network. 1. The MobilityClients and H3Services use the LISP XTR network over tunnels to mitigate multi-access-provider multi-edge-provider challenges such as NAT or multi-tenancy in clusters or edge device OS. The simplest choice is to use data-path LISP tunnels: -ClientXTR -ServerXTR But these do not participate in the mapping control plane. Mapping System / \ sXTR=RTR1 :: RTR2=cXTR 2. Nexagon is a mobility geospatial pub-sub network, road-segments are abstracted to EIDH3Services which are administratively provisioned based on load/availability to RTRs and the mapping system accordingly. Their global RLOC is their RTR (RTRs in multi homing). Clients subscribe to these geospatial feed using MLD and SignalFree Mcast, which means their RTRs subscribe for them to (s,g) feeds. Their RTRs are assigned by AAA. The AAA provisioning is done both at the client and the RTR. The RTR does mcast replication to to all the clients it is homing and that have MLD subscribed through them to (s,g) or (location, theme) mcast feeds. After they subscribe, some of the clients may also publish geospatial detections, depending on their EID credentials (rw/ro). When they do the RTR RLOC of the H3Service (this time as dest EID) is gleaned into the map-cache of the client RTR - which is subscribed to that H3EIDService as a feed (source). Clients may NOT talk to each-other or learn each other's EIDs. The Nexagon network overlay is strictly brokered. If the above computes, welcome any suggestion that prevents reading the draft differently. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 On Feb 8, 2021, at 12:05, Albert López wrote: Hi Sharon, Thanks for your clarifications. I have some questions inline. On 5/2/21 13:31, Sharon wrote: Thank you Albert. These are very good comments. See inline: --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 On Feb 5, 2021, at 12:26, Albert López wrote: Hi all, After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done. Some comments and questions that I have when reading the document are the following ones: In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them. I will add more text on the nexagon header. In principle these are: Type: we specify two types only here kv, kv, kv... basic and default use v, k, k, k .. for large area with same value proprietary extensions add more types Gzip: is a flag if the k,v where zipped. In close by tiles the compression is high Reserved: Pair count: how many kv are we sending, in kv kv or v kkk form "/EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)/" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs? The LISP default is option1 clients and servers are not homed to the same RTR. This is for example in a MEC or Wavelength type deployment. In this option the servers EID are registered in the mapping with the RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does not participate in the lisp control plane. The clientXTR and ServerXTR solve NAT traversal between mobile and edge providers. So, if I understood correctly, the serverXTR is registering its EID (H3.r9) to the mapping system using the RLOC of its associated RTR. Right This process is done through Encap Map-Register of the serverXTR through the RTR or It is the serverXTR who is sending directly a Map-Register to the mapping system? Provisioned How does the RTR knows the the real RLOC of the serverXTR? is statically configured? or is learned through an Encap Map-Register? Through gleaning the feed from the server it signal-free subscribed to We left the door open to a more distributed implementation for example by cell towers or RSU. In this case there is only one RTR between clients and servers. "/EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network./": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
Thanks Albert for pointing out these possible confusion points. Answering inline .. But first would like to clarify the exact subset of LISP we leverage for the Nexagon mobility network. 1. The MobilityClients and H3Services use the LISP XTR network over tunnels to mitigate multi-access-provider multi-edge-provider challenges such as NAT or multi-tenancy in clusters or edge device OS. The simplest choice is to use data-path LISP tunnels: -ClientXTR -ServerXTR But these do not participate in the mapping control plane. Mapping System /\ sXTR=RTR1 :: RTR2=cXTR 2. Nexagon is a mobility geospatial pub-sub network, road-segments are abstracted to EIDH3Services which are administratively provisioned based on load/availability to RTRs and the mapping system accordingly. Their global RLOC is their RTR (RTRs in multi homing). Clients subscribe to these geospatial feed using MLD and SignalFree Mcast, which means their RTRs subscribe for them to (s,g) feeds. Their RTRs are assigned by AAA. The AAA provisioning is done both at the client and the RTR. The RTR does mcast replication to to all the clients it is homing and that have MLD subscribed through them to (s,g) or (location, theme) mcast feeds. After they subscribe, some of the clients may also publish geospatial detections, depending on their EID credentials (rw/ro). When they do the RTR RLOC of the H3Service (this time as dest EID) is gleaned into the map-cache of the client RTR - which is subscribed to that H3EIDService as a feed (source). Clients may NOT talk to each-other or learn each other's EIDs. The Nexagon network overlay is strictly brokered. If the above computes, welcome any suggestion that prevents reading the draft differently. --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 8, 2021, at 12:05, Albert López wrote: > > > Hi Sharon, > > Thanks for your clarifications. I have some questions inline. > >> On 5/2/21 13:31, Sharon wrote: >> Thank you Albert. These are very good comments. See inline: >> >> --szb >> Cell: +972.53.2470068 >> WhatsApp: +1.650.492.0794 >> >>> On Feb 5, 2021, at 12:26, Albert López wrote: >>> >>> >>> Hi all, >>> >>> After reading the draft, I believe it is a really good idea, but I think >>> that the document needs more work to be done. >>> >>> Some comments and questions that I have when reading the document are the >>> following ones: >>> >>> In section 6, the structure of a "Nexgon packet" is introduced with the >>> Nexgon header but no description is provided of the fields of this header. >>> After reading the document you can deduce the use of some of these fields >>> but not all of them. >> >> I will add more text on the nexagon header. In principle these are: >> >> Type: we specify two types only here >> kv, kv, kv... basic and default use >> v, k, k, k .. for large area with same value >> proprietary extensions add more types >> >> Gzip: is a flag if the k,v where zipped. >> In close by tiles the compression is high >> >> Reserved: >> >> Pair count: how many kv are we sending, >> in kv kv or v kkk form >> >>> >>> "EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR >>> (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no >>> more information is provided about option1 and option2. The scenario is >>> clear for me when we have one EdgeRTR between client-XTR and server-XTR but >>> when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I >>> don't understand when to use it and the process to implement it. Is it >>> using ELPs? >> >> The LISP default is option1 clients and servers are not homed to the same >> RTR. This is for example in a MEC or Wavelength type deployment. In this >> option the servers EID are registered in the mapping with the RLOC of their >> RTR. The ServerXTR is just a tunnel to the RTR and does not participate in >> the lisp control plane. The clientXTR and ServerXTR solve NAT traversal >> between mobile and edge providers. > So, if I understood correctly, the serverXTR is registering its EID (H3.r9) > to the mapping system using the RLOC of its associated RTR. Right > This process is done through Encap Map-Register of the serverXTR through the > RTR or It is the serverXTR who is sending directly a Map-Register to the > mapping system? Provisioned > How does the RTR knows the the real RLOC of the serverXTR? is statically > configured? or is learned through an Encap Map-Register? Through gleaning the feed from the server it signal-free subscribed to >> >> We left the door open to a more distributed implementation for example by >> cell towers or RSU. In this case there is only one RTR between clients and >> servers. >> >>> >>> "EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as >>> these are temporary-renewed while using the mobility network.": Does the >>>
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
Hi Sharon, Thanks for your clarifications. I have some questions inline. On 5/2/21 13:31, Sharon wrote: Thank you Albert. These are very good comments. See inline: --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 On Feb 5, 2021, at 12:26, Albert López wrote: Hi all, After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done. Some comments and questions that I have when reading the document are the following ones: In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them. I will add more text on the nexagon header. In principle these are: Type: we specify two types only here kv, kv, kv... basic and default use v, k, k, k .. for large area with same value proprietary extensions add more types Gzip: is a flag if the k,v where zipped. In close by tiles the compression is high Reserved: Pair count: how many kv are we sending, in kv kv or v kkk form "/EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)/" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs? The LISP default is option1 clients and servers are not homed to the same RTR. This is for example in a MEC or Wavelength type deployment. In this option the servers EID are registered in the mapping with the RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does not participate in the lisp control plane. The clientXTR and ServerXTR solve NAT traversal between mobile and edge providers. So, if I understood correctly, the serverXTR is registering its EID (H3.r9) to the mapping system using the RLOC of its associated RTR. This process is done through Encap Map-Register of the serverXTR through the RTR or It is the serverXTR who is sending directly a Map-Register to the mapping system? How does the RTR knows the the real RLOC of the serverXTR? is statically configured? or is learned through an Encap Map-Register? We left the door open to a more distributed implementation for example by cell towers or RSU. In this case there is only one RTR between clients and servers. "/EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network./": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR? At this point we do not allow unicast between clients, only publish clients to servers, and signal free feed servers to clients. If no registration process exists of the MobilityClients' EID, how does the edgeRTR knows the MobilityClient's RLOC that should be used to send the multicast packets? (Specially if a change of RLOC is produced) Best regards Albert Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section? Yes clients can repeat AAA procedure and are supposed to renew AAA. I think that more references need to be added to the document like the DIAMETER RFC. Will add I hope these comments could help to improve the document. They do. I will clarify the language and send update as soon as all inputs are in. Thank you for devoting the time and attention. Best regards Albert López On 3/2/21 16:25, Luigi Iannone wrote: Hi All, The authors of draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review. No further comments have been raised and the authors consider the document stable and ready for WG Last Call. This email open the usual two weeks Working Group Last Call, to end February 17th, 2021. Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD. If you have objections, please state your reasons why, and explain what it would take to address your concerns. NOTE: silence IS NOT consensus! Thanks Luigi & Joel ___ 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 mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
Thank you Albert. These are very good comments. See inline: --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 5, 2021, at 12:26, Albert López wrote: > > > Hi all, > > After reading the draft, I believe it is a really good idea, but I think that > the document needs more work to be done. > > Some comments and questions that I have when reading the document are the > following ones: > > In section 6, the structure of a "Nexgon packet" is introduced with the > Nexgon header but no description is provided of the fields of this header. > After reading the document you can deduce the use of some of these fields but > not all of them. I will add more text on the nexagon header. In principle these are: Type: we specify two types only here kv, kv, kv... basic and default use v, k, k, k .. for large area with same value proprietary extensions add more types Gzip: is a flag if the k,v where zipped. In close by tiles the compression is high Reserved: Pair count: how many kv are we sending, in kv kv or v kkk form > > "EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR > (option 1) or to homed H3ServiceEID ServerXTR (option 2)" but I think no more > information is provided about option1 and option2. The scenario is clear for > me when we have one EdgeRTR between client-XTR and server-XTR but when we > have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't > understand when to use it and the process to implement it. Is it using ELPs? The LISP default is option1 clients and servers are not homed to the same RTR. This is for example in a MEC or Wavelength type deployment. In this option the servers EID are registered in the mapping with the RLOC of their RTR. The ServerXTR is just a tunnel to the RTR and does not participate in the lisp control plane. The clientXTR and ServerXTR solve NAT traversal between mobile and edge providers. We left the door open to a more distributed implementation for example by cell towers or RSU. In this case there is only one RTR between clients and servers. > > "EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as > these are temporary-renewed while using the mobility network.": Does the > Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the > Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can > we consider the EdgeRTR as the MS of the Client-xTR? At this point we do not allow unicast between clients, only publish clients to servers, and signal free feed servers to clients. > > Is there any mechanism contemplated for the MobilityClient to change the > associated EdgeRTRs? for instance repeating the procedure explained in > section 4 when changing to a new H3.9 section? > Yes clients can repeat AAA procedure and are supposed to renew AAA. > I think that more references need to be added to the document like the > DIAMETER RFC. > Will add > I hope these comments could help to improve the document. > They do. I will clarify the language and send update as soon as all inputs are in. Thank you for devoting the time and attention. > Best regards > > Albert López > > > > >> On 3/2/21 16:25, Luigi Iannone wrote: >> Hi All, >> >> The authors of draft-ietf-lisp-nexagon submitted the current version back >> in October solving issues raised during SECDIR review. >> No further comments have been raised and the authors consider the document >> stable and ready for WG Last Call. >> >> This email open the usual two weeks Working Group Last Call, to end February >> 17th, 2021. >> >> Please review this WG document and let the WG know if you agree that it is >> ready to be handed over to the AD. >> If you have objections, please state your reasons why, and explain what it >> would take to address your concerns. >> >> NOTE: silence IS NOT consensus! >> >> Thanks >> >> Luigi & Joel >> >> >> ___ >> 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 mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
Hi all, After reading the draft, I believe it is a really good idea, but I think that the document needs more work to be done. Some comments and questions that I have when reading the document are the following ones: In section 6, the structure of a "Nexgon packet" is introduced with the Nexgon header but no description is provided of the fields of this header. After reading the document you can deduce the use of some of these fields but not all of them. "/EdgeRTRs then re-encapsulates annotation packets either to remote EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)/" but I think no more information is provided about option1 and option2. The scenario is clear for me when we have one EdgeRTR between client-XTR and server-XTR but when we have to reencapsulate packets from EdgeRTR to another EdgeRTR I don't understand when to use it and the process to implement it. Is it using ELPs? "/EdgeRTRs do not register MobilityClients’ EIDs at the mapping service as these are temporary-renewed while using the mobility network./": Does the Client-XTR send Map Registers to the EdgeRTR? If not, how does it know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR? Is there any mechanism contemplated for the MobilityClient to change the associated EdgeRTRs? for instance repeating the procedure explained in section 4 when changing to a new H3.9 section? I think that more references need to be added to the document like the DIAMETER RFC. I hope these comments could help to improve the document. Best regards Albert López On 3/2/21 16:25, Luigi Iannone wrote: Hi All, The authors of draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review. No further comments have been raised and the authors consider the document stable and ready for WG Last Call. This email open the usual two weeks Working Group Last Call, to end February 17th, 2021. Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD. If you have objections, please state your reasons why, and explain what it would take to address your concerns. NOTE: silence IS NOT consensus! Thanks Luigi & Joel ___ 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] WG Last Call for draft-ietf-lisp-nexagon
Hi, I think the document is ready to be handed to the AD. Best regards, -Lori > On Feb 3, 2021, at 6:57 PM, Sharon Barkai > wrote: > > Thank you Luigi Joel. > > We are working to add LISP based digital-twin interface for road segments to > the AECC auto-edge. The roll of this interface is to throttle the pipes: car > access to edge, edge to cloud by: > > 1. Recording car EID data-handles in tile EID ledgers for selective uploads > per quota > 2. Aggregating coalescing filtering uploads per tile for reduced feed to > cloud applications > > This is hard to do with an IETF draft so very much appreciate show of support > even though its the 2nd such poll... > > --szb > Cell: +972.53.2470068 > WhatsApp: +1.650.492.0794 > >> On Feb 3, 2021, at 17:25, Luigi Iannone wrote: >> >> Hi All, >> >> The authors of draft-ietf-lisp-nexagon submitted the current version back >> in October solving issues raised during SECDIR review. >> No further comments have been raised and the authors consider the document >> stable and ready for WG Last Call. >> >> This email open the usual two weeks Working Group Last Call, to end February >> 17th, 2021. >> >> Please review this WG document and let the WG know if you agree that it is >> ready to be handed over to the AD. >> If you have objections, please state your reasons why, and explain what it >> would take to address your concerns. >> >> NOTE: silence IS NOT consensus! >> >> Thanks >> >> Luigi & Joel >> ___ >> 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 smime.p7s Description: S/MIME cryptographic signature ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] WG Last Call for draft-ietf-lisp-nexagon
Thank you Luigi Joel. We are working to add LISP based digital-twin interface for road segments to the AECC auto-edge. The roll of this interface is to throttle the pipes: car access to edge, edge to cloud by: 1. Recording car EID data-handles in tile EID ledgers for selective uploads per quota 2. Aggregating coalescing filtering uploads per tile for reduced feed to cloud applications This is hard to do with an IETF draft so very much appreciate show of support even though its the 2nd such poll... --szb Cell: +972.53.2470068 WhatsApp: +1.650.492.0794 > On Feb 3, 2021, at 17:25, Luigi Iannone wrote: > > Hi All, > > The authors of draft-ietf-lisp-nexagon submitted the current version back in > October solving issues raised during SECDIR review. > No further comments have been raised and the authors consider the document > stable and ready for WG Last Call. > > This email open the usual two weeks Working Group Last Call, to end February > 17th, 2021. > > Please review this WG document and let the WG know if you agree that it is > ready to be handed over to the AD. > If you have objections, please state your reasons why, and explain what it > would take to address your concerns. > > NOTE: silence IS NOT consensus! > > Thanks > > Luigi & Joel > ___ > 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] WG Last Call for draft-ietf-lisp-nexagon
Hi All, The authors of draft-ietf-lisp-nexagon submitted the current version back in October solving issues raised during SECDIR review. No further comments have been raised and the authors consider the document stable and ready for WG Last Call. This email open the usual two weeks Working Group Last Call, to end February 17th, 2021. Please review this WG document and let the WG know if you agree that it is ready to be handed over to the AD. If you have objections, please state your reasons why, and explain what it would take to address your concerns. NOTE: silence IS NOT consensus! Thanks Luigi & Joel___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
