Hello Albert, Thanks for your speedy turn-around.
>> DISCUSS: >> ---------------------------------------------------------------------- >> >> 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. > > Agreed, I´ll remove the first sentence. Perfect >> 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. > > Agreed, I´ll remove the first paragraph and first four words of the > second paragraph. Also perfect. >> COMMENT: >> ---------------------------------------------------------------------- Please note that Comments are just my observations. You are not obliged to make changes or pay attention. You just need to reach equilibrium with your AD. >> 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]" >> > The same reference is cited in RFC4984 and RFC4423, it is preferable > to cite it as it is or cite RFC4984? Per Brian, 4984 would be fine. >> 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 possibility 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 consistency 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? > > Agreed, as you suggest I will state that EIDs and RLOCs are IP addresses, > which > basically means removing the word "typically". Why don't you say "addresses" instead of "typically IP addresses"? That is then open to the flexibility of LCAF while still embracing IP addresses. > I also think that the text that you highlighted is sufficient to explain that > LCAF supports more general address encoding. Please let me know if this > addresses your comment. I think it would *if* you make the change to "addresses". >> 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 >> and 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 "reserved address block"? > > Thanks for your comment, I suggest rephrasing the bullet point in the > following way: > > EIDs have meaning only in the overlay network, which is the encapsulation > relationship between LISP-capable routers. > > Then Section 3.2 mentions the EID leakage as well as its assignment. A fine change. Note that you are addressing my specific example, giving a little bit more of a clue about what an overlay is, but not handling the general problem that the Introduction may be going to deep, or fully explaining overlay/underlay. [snipped agreement] >> 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"? > > What about? > > Adding LISP capabilities to routers does not mandate hardware changes > and can be done via a software upgrade. If that's true (and I have no reason to doubt you), then that works. >> 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. > > I would prefer to avoid using the word MUST since this document > does not specify LISP. Agreed. My bad choice of emphasis marker! > I suggest rephrasing the bullet point in the > following way: > > Time-To-Live (TTL): Each mapping contains a TTL set by the ETR, upon > expiration of the TTL the ITR can't use the mapping until it is > refreshed by > sending a new Map-Request. Typical values for TTL defined by LISP > are 24 hours. That works. >> Section 5 says [snip] > I suggest the following sentence: > > The separation between locators and identifiers in LISP was initially > motivated by discussions during the IAB-sponsored Workshop, the outcomes are > described in RFC4984. Great. s/are/of which/ [snipped agreement] Many thanks again for the work. Adrian _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
