Hi Brian, all,
Thank you for your thorough review and useful feedback. See inline
below for replies to your remarks. We accepted your suggested changes
in case of remarks that we don't reply to.
On 5/14/13 8:37 PM, Brian Haberman wrote:
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.
How about this wording: "Encapsulation may result in a decrease of the
end-to-end path MTU, if encapsulated packets need to travel over links
with MTU lower than 1500 bytes + LISP encapsulation overhead."
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)?
We don't object to removing the bullet referencing the draft.
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.
Is it appropriate to reference individual submission drafts, if there
are plans to have them become IETF WG drafts? In that case we could
reference draft-ermagan-lisp-nat-traversal, which offers a complete
solution to NAT traversal. There are already two implementations of
this drafts that I know of.
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.
How about this introductory text?
"The following table gives a quick overview of the features supported by
each of the deployment scenarios discussed above (marked with an "x") in
the appropriate column: "CE" for customer edge, "PE" for provider edge,
"Split" for split ITR/ETR, and "Recursive" for inter-service provider
traffic engineering."
Should we explain the features themselves in more detail as well?
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?
Section 3 was structured differently, because Map Servers/Resolvers are
not edge devices as tunnel routers, and the LISP protocol was designed
assuming they will not be deployed behind NAT. Not even the NAT
traversal draft mentioned above introduces support for it. We will make
note of this in section 3.
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?
What we intended to say here is that Map Server redundancy is out of
scope for this document, because deployments should take advantage of
the existing knowledge about the technology behind the mapping system.
Since ALT is based on BGP, and DDT was inspired from DNS, deployments
can leverage current industry practices for redundancy in BGP and DNS.
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?
I'm not aware of any conclusive study on this subject, that's why we
worded the statement "may lead to a decrease" and explicitly mentioned
the "late transition phase", when most sites use LISP.
14. Section 5.3
* The second paragraph mentions "additional costs for the PSP". I would
like to see some example costs highlighted.
We will remove the last sentence of the second paragraph.
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?
The focus on DFZ routing table size is due to the charter of the LISP
WG, and the direction set by the chairs when writing the document, since
LISP is one of the proposals designed to address RFC 4984.
The concerns about routing/forwarding and application-level performance
are legitimate. However, the effects of decreased message size from
encapsulation on application-level performance are not specific to LISP,
so we didn't discuss it in detail.
We don't have data on RTT increase due to LISP migration yet, since
production deployments are still emerging. Maybe a bis document could
be published one more data will be available?
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?
In order to help xTR deployments, we offered this section as a
step-by-step guide for the operational community. Should we make it an
appendix in this case?
* Step 4 talks about verifying that local routers do not filter certain
ICMP messages. What about filtering of those ICMP messages by upstream
ISPs?
While it does happen, it is less common that transit ISPs completely
filter those ICMP messages, since they are necessary for traceroute,
which is a valuable tool for the operational community. Of course, if
issues are detected during operation, the appropriate ISP can be
contacted, like for any other issue today.
* 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.
They are offered by the LISP pilot network, and are intended to be kept
stable. However, we don't object to removing that sentence.
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
