-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All,
On 3/6/15 3:02 PM, Adrian Farrel wrote: >>> 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. Good. > >>> 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. This makes sense to me. > >> 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". Agreed. > >>> 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. Based on Alia's review, this whole sentence will be gone. > >>> 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. Agreed. > >>> 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/ > Agreed. Regards, Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU+gumAAoJEBOZRqCi7goqXjoH/iuhyBIs9i6kq4fdz9Mqj2w7 fbxgwn54ElBNg2SXmS5XPmVwUIKQMy3ufWDvXp/tgUbTtuRZ6Yj6q4Km5EOh6RY1 fZ32l69hvpCxX34MBKnv8xK8CO3y+tuXTzh7Et4CBN13Gh3jUGFJhwTcan1IX7K7 2eii+TUYweRFH33yrXPe7SuoMrWh6c38gXySq6BDXala/KRFy+27WXOwYn/X7nq3 GnS+avh6moaUmQJSY1+Rsr8+NKqHCQq30ucLAqVBryzGPSBIwEL1Qfht0MTyd9gI 3A/IGz8Wvq5pHdNRkgK4ViBBnZl7xC77UfdUmYq5KPXTGLTPSP75WGQPG25Qzxw= =Fg7y -----END PGP SIGNATURE----- _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
