All,
I have completed my AD Evaluation of draft-ietf-lisp-deployment.
I have some comments/questions that need to be resolved before we can
move the document along to an IETF Last Call.
1. The document leverages several terms that are not defined in this
document. It would be useful to point out where those terms are
defined. Terms that I came across that should be referenced (or defined
locally) are: map-and-encap, Loc-Status-Bits, PoPs, and path stretch.
2. Introduction
* s/(LISP) addresses the/(LISP) is designed to address the/
* s/LISP go beyond of just/LISP go beyond just/
* s/the draft we/the document we/
* I see variations of "LISP site" within the document (LISP site, LISP
Site, LISP end site). Please pick one term and make it consistent.
* The lead-in text to the definition of "LISP site" has no mention of
the definition of "Network element". It would be useful to say that the
document is defining two new terms.
* s/is connected connected to/is connected to/
3. Section 2
* s/is called Tunnel Router/is called a Tunnel Router/
4. Section 2.1
* s/placing tunnel routers are MTU/placing tunnel routers is MTU/
* The sentence that starts "Since encapsulating packets increases..." is
rather convoluted and hard to parse. I would suggest re-wording it.
5. Section 2.2
* s/LISP site looses one/LISP site loses one/
6. Section 2.3
* s/considers that both entities can/ allows both entities to/
* The second paragraph says that BGP policy determines the best egress
point. Aren't there more issues to consider than just BGP policy?
Address selection policy and IGP link metrics come to mind in this model
as well. I think it would be cleaner to simply say that egress point
selection is driven by operational policy or some such.
* s/ISPs is doing/ISPs are doing/
7. Section 2.4
* The whole description of inter-ISP TE seems incomplete, yet still
wildly complex. I would have expected some discussion of scaling issues
with applying LISP recursively. This is especially true considering the
amount of information coordination needed to make it work.
* This section references the lisp-eid-block draft (albeit
informatively). Given the current state of that draft, is the
associated text in this draft really needed (or beneficial)?
8. Section 2.5.1
* The discussion of NAT traversal may benefit from some additional text
that points at PCP as an alternative to static hole-punching.
9. Section 2.6
* It would be much clearer if there was some supporting text for the
summary matrix. It is rather confusing to understand what the table is
trying to tell the reader.
10. Section 3
* This section seems to be lacking the level of detail provided in
Section 2.*. Are there any issues with deploying Map Servers/Resolvers
behind NATs? In provider (vs. customer) networks?
11. Section 3.1
* It may be useful to provide a reference for ALT and DDT.
* There is an extraneous "SHOULD" in the second paragraph that needs to
be moved to lower-case.
* The next-to-last paragraph mentions "known mapping system specific
best practices". Are these documented anywhere?
12. Section 3.2
* s/A Map Resolver a is/A Map Resolver is/
* There is mention of providing anycast RLOCs. It may be useful to
reference 4786 for this type of service.
* s/helps improving mapping/helps improve mapping/
13. Section 5.1
* I would like to see some justification for the statement that the
increase in LISP deployment will reduce the need for BGP-based TE. I
can envision some scenarios where LISP could increase the BGP-based TE
in order to access the "correct" ETR (or P-ETR). Is there some studies
that back up this claim?
14. Section 5.3
* The second paragraph mentions "additional costs for the PSP". I would
like to see some example costs highlighted.
15. Section 5.4
* The table discussing the potential benefits for DFZ route table size
is interesting. But, that is only one metric and one that end-users
probably don't care about. Is there some data on the overall
routing/forwarding performance? For example, v4/v6 tunneling has been
shown to increase RTT (due to inefficient paths). Will LISP have
similar issues? What about the application-level performance due to
decreased message size from encapsulation?
16. Section 6
* This whole section seems out of place compared to the rest of the
document. There is no descriptive text introducing the section and
reads more like a vendor's checklist. How does it relate to the rest of
the document?
* Step 4 talks about verifying that local routers do not filter certain
ICMP messages. What about filtering of those ICMP messages by upstream
ISPs?
* Step 5 : s/provivers/providers/
17. Section 6.2
* Are the URLs in step 2 stable? It is generally bad form to include
such URLs in an RFC since they may become stale/obsolete.
Feel free to discuss these issues with me as you resolve them.
Regards,
Brian
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
