> Hi Dino > > Thanks for your comments, please find below our answers:
Thanks for the volume of responses. Way to stay on top of this. See my responses below. I have cut out text that I agree with or have no resposne to. >> >> Change "supra" to "super". But saying super-linear is like saying "that was >> a long minute". ;-) I think you should say exponential slope. >> > > I think that the correct mathematical term is supralinear: > > http://en.wiktionary.org/wiki/supralinear I am not questioning the definition of supra linear, I just think we should use exponential because we have done so so many times before. Not a big deal. >>> ITRs and ETRs exchange packets by encapsulating them, hence LISP >>> operates as an overlay to the current Internet core. >> >> Well this is technically not true. ITRs encapsulate and ETRs decapsulate. >> > > I´ve rephrased this paragraph, let´s see if this one is better: > > 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. When they ingress packets from the LISP site into the "ingress packets from the LISP site" makes it sound like the packets are going *into* the site. Why not just keep the language simple and say "When packets originated from a LISP site are flowing towards the core network, they ingress into an encapsulated tunnel via an Ingress Tunnel Router (ITR).". > tunnel they are called Ingress Tunnel Router (ITR), Egress Tunnel > Router (ETR) when they egress packets from the core to the LISP site > and xTR when they can perform both operations. In this context ITRs > encapsulate packets while ETRs decapsulate them, hence LISP operates > as an overlay to the current Internet core. And "When packets flow from the core network to a LISP site, they egress from an encapsulated tunnel to an Egress Tunnel Router (ETR).". >> This is not true. The Map-Server advertises registered EID-prefixes by the >> ETR. The Map-Server advertises such EID-prefixes to ALT routers via BGP. >> Then Map-Requests can be routed on the ALT topology so an ITR's Map-Request >> can get from Map-Resolver, to ALT-router, to ALT-router, then finally the >> Map-Server which then can proxy-reply or forward the Map-Request to the ETR >> to reply. >> >> Please fix this paragraph. > > See my updated paragraph below: > > The LISP Alternative Topology (LISP+ALT) [RFC6836] was the first > Mapping System proposed, developed and deployed on the LISP pilot > network. It is based on a distributed BGP overlay participated by > Map-Servers and Map-Resolvers. The nodes connect to their peers "... Map-Resolvers, Map-Servers, and ALT routers. ...". > through static tunnels. Each Map-Server involved in the ALT topology > advertises the EID-prefixes registered by the serviced ETRs, making > the EID routable on the ALT topology. "... on the ALT topology so Map-Requests can flow from Map-Resolvers through the ALT topology to the Map-Server the EID was registered to". >>> >>> In order to resolve a query LISP-DDT operates iteratively and in a >>> similar way to the DNS. DDT clients (usually Map-Resolvers) generate >> >> It may worth saying that DDT does not do recursive lookups like DNS but does >> do iterative lookups like DNS. >> > > Why stating what DDT is not? I think that this way is shorter and clearer. Because if you state that DDT is DNS, then people may assume that recurisve lookups are done as they are in DNS. DNS has recursive and iterative lookups. DDT only borrowed the iterative lookup idea from DNS. >>> RLOC-probing: This is an active probing algorithm where ITRs send >>> probes to specific locators, this effectively probes both the locator >>> and the path. In particular this is done by sending a Map-Request >>> (with certain flags activated) on the data-plane and waiting in >> >> This is misleading. An RLOC-probe is a Map-Request. A Map-Request is a >> control-plane packet. > > Can you please further clarify this comment? Are you suggesting > removing “(with certain flags activated)”? Yes, change to "In particular this is done by sending a Map-Request with the probe-bit set to 1 to the RLOC of the ETR". >>> return a Map-Reply, also sent on the data-plane. The active nature >>> of RLOC-probing provides an effective mechanism to determine >>> reachability and, in case of failure, switching to a different >>> locator. Furthermore the mechanism also provides useful RTT >>> estimates of the delay of the path that can be used by other network >>> algorithms. >> >> We should say that echo-noncing and RLOC-probing can work together. That is >> if a nonce is not echoed, a ITR could RLOC-probe to determine if the path is >> up (because the return bidirectional path may have went silent). Or, when >> echo-noncing determines a forward path to an RLOC is up, RLOC-probes can be >> suppressed to save sending extra messages. >> > > See my updated paragraph below: > > It is worth noting that RLOC probing and Echo-nonce can work together. > Specifically if a nonce is not echoed, an ITR could RLOC-probe to > determine if the path is up because the return bidirectional path may > have failed. Alternatively, when echo-noncing determines a forward Or the the return path is not used. That is there is only a unidirectional path. > path to an RLOC is up, RLOC-probes can be suppressed to save messages. This part to explain suppressing RLOC-probes is good. > >>> mapping system are used instead of BGP and the LISP encapsulation is >>> used to replace MPLS. >> >> I think comparing to BGP/MPLS does not help describe what it is. And it is >> not a wholesale replacement because BGP/MPLS VPNs typically run within a >> single ISP where LISP VPNs can run anywhere (i.e. a mobile phone can be in a >> VPN and encapsulates to a multi-tennant environment in the data center). > > what about just keeping > > It is nowadays common to operate several virtual private networks over > the same physical infrastructure. Agree. > >>> When a subnetwork detects the presence of a host with an address that >>> does not belong to the subnetwork (e.g., via a message sent by the >>> hypervisor), the LISP router of the new subnetwork registers the IP >> >> Remove the parenthetitcal comment. You don't want to assume what is moving >> is only VMs. A server can be relocated. xTRs discover dynamic-EIDs by >> listening to packets and ARP messages to discover new sources. > > hence the e.g., and not an i.e., > > what about: > (e.g., via a message sent by the hypervisor or traffic inspection) I think it is too specific for this document. Thanks a lot, Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
