I’ll send a new -09 update to the list in my reply to Padma’s email. >> >> Client-side: Client-side is a term used in this document to indicate >> a connection initiation attempt by an EID. >> > [Luigi] > As stated for -07. > Following sentence not needed here. (it is specified in the operation part of > the document) >> The ITR(s) at the LISP >> site are the first to get involved in forwarding a packet from the >> source EID.
I have changed the text to reflect Padma’s suggestion. >> >> >> Re-Encapsulating Tunneling Router (RTR): An RTR acts like an ETR to >> remove a LISP header, then acts as an ITR to prepend a new LISP >> header. This is known as Re-encapsulating Tunneling. Doing this >> allows a packet to be re-routed by the RTR without adding the >> overhead of additional tunnel headers. >> > [Luigi] > As stated for -07. > Following sentence not needed here. (it is specified in the operation part of > the document) > Delete from here: >> Any references to tunnels >> in this specification refer to dynamic encapsulating tunnels; they >> are never statically configured. Removed. >> Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 >> [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is >> the output of an EID-to-RLOC mapping lookup. An EID maps to one >> or more RLOCs. Typically, RLOCs are numbered from aggregatable >> blocks >> > remove “Agregatable” Removed. > > [Luigi] > As stated for -07 and discussed later: merge the three bullets above so to > simplify the flow. > Here is the proposed single-bullet text: > > o End-systems only send to addresses that are EIDs. EIDs are typically > IP addresses assigned to hosts (other types of EID are supported by > LISP, > see [RFC8060] for further information). End-systems don't know > that addresses are EIDs versus RLOCs but assume that packets get > to their intended destinations. In a system where LISP is > deployed, LISP routers intercept EID-addressed packets and assist > in delivering them across the network core where EIDs cannot be > routed. The procedure a host uses to send IP packets does not > change. Replaced with your merged text. >> >> o EID-Prefixes are likely to be hierarchically assigned in a manner >> that is optimized for administrative convenience and to facilitate >> scaling of the EID-to-RLOC mapping database. >> > [Luigi] > As stated for -07 the above bullet (even if modified compare to -07) is about > scalability and should be removed. Removed. A shame but removed. >> o EIDs MAY also be structured (subnetted) in a manner suitable for >> local routing within an Autonomous System (AS). >> >> >> >> LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is >> randomly generated by an ITR when the N-bit is set to 1. Nonce >> generation algorithms are an implementation matter but are >> required to generate different nonces when sending to different >> destinations. >> > [Luigi] > As stated for -07: What is a destination? Should be different RLOCs, for > clarity. Changed to " when encapsulating to the same ETR”. >> [Luigi] > The following part is the ECN part and as afar as I cans is the only change > proposed in -09 > (09 includes the text proposed by Albert) It is all Albert’s text. > > >> When doing ITR/PITR encapsulation: >> >> >> Farinacci, et al. Expires July 13, 2018 [Page 22] >> Internet-Draft LISP January 2018 >> >> >> 9. Routing Locator Selection >> > [Luigi] > As stated for -07: > > Large part of this section is about control plane issues and as such should > be put in 6833bis. > > What this section should state is that priority and weight are used to select > the RLOC to use. > Only exception is gleaning where we have one single RLOC and we do not know > neither priority nor weight. > > All the other operational discussion goes elsewhere, but not in this document. Not changing this to we get more concensus from the working group. >> >> 10. Routing Locator Reachability >> >> Several mechanisms for determining RLOC reachability are currently >> defined: >> > [Luigi] > As stated for -07: > > There exists data-plane based reachability mechanisms and control plane > reachability mechanisms. > We have to keep here only the data plane based mechanism and move the other > in 6833bis. All the reachability mechanisms are used for the data-plane. > > We need to keep: 1, 6, Echo-Nonce, > > We need to move: 2, 3, 4, 5, RLOC-Probing Not changing this to we get more concensus from the working group. > > >> >> >> When ITRs at the site are not deployed in CE routers, the IGP can >> still be used to determine the reachability of Locators, provided >> they are injected into the IGP. This is typically done when a /32 >> address is configured on a loopback interface. >> >> > [Luigi] > As stated for -07: The above paragraph has to move to 6833bis. For all your comments like this. I am not changing until there is more concensus from the working group. > > The fact that (P)ITRs use this mechanism does make it a data-plane mechanism. > is the LISP control plane running on (P)ITRs that does it, using control > plane messages. >> RLOC-Probing is a method that an ITR or PITR can use to determine the >> reachability status of one or more Locators that it has cached in a >> Map-Cache entry. The probe-bit of the Map-Request and Map-Reply >> messages is used for RLOC-Probing. No one said PITRs are special or different than ITRs in this regard. For both, they use the control plane messages to determine reachabiltity for RLOCs that THE DATA-PLANE encapsulates to. The data-plane operation decides based on packet counter, RTT, TTL and other mechanisms if the RLOC is of quality for use. Any other entity that doesn’t do packet forwarding that does mapping system lookups doesn’t consider these things. Hence, why this issue of the control-plane needs to be described in the document related to packet forwarding. >> 19. Security Considerations >> >> Security considerations for LISP are discussed in [RFC7833], in >> addition [I-D.ietf-lisp-sec] provides authentication and integrity to >> LISP mappings. >> > [Luigi] > As stated for -07: > > lisp-sec is control-plane has to be referenced in 6833bis. > > authentication and integrity of mappings is a control plane issue. Removed. > >> A complete LISP threat analysis can be found in [RFC7835], in what >> follows we provide a summary. >> >> >> >> lisp-data 4341 udp LISP Data Packets >> lisp-control 4342 udp LISP Control Packets >> > [Luigi] > As stated for -07: > > 4342 is control-plane and MUST be requested to IANA in the 6833bis document. Removed and will be moved to RFC6833. Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
