Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
Hi Fred, On 05/29/2013 08:32 PM, Templin, Fred L wrote: Hi Lori, -Original Message- From: Lori Jakab [mailto:lja...@ac.upc.edu] Sent: Wednesday, May 29, 2013 9:58 AM To: Templin, Fred L Cc: Paul Vinciguerra; Lori Jakab; Brian Haberman; draft-ietf-lisp- deploym...@tools.ietf.org; lisp@ietf.org Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment On 05/28/2013 11:38 PM, Templin, Fred L wrote: -Original Message- From: Paul Vinciguerra [mailto:pvi...@vinciconsulting.com] Sent: Tuesday, May 28, 2013 12:58 PM To: Templin, Fred L; Lori Jakab; Brian Haberman Cc: draft-ietf-lisp-deploym...@tools.ietf.org; lisp@ietf.org Subject: RE: [lisp] AD Evaluation: draft-ietf-lisp-deployment Encapsulation results in an end-to-end path MTU of less than 1500 bytes, if encapsulated packets need to travel over links with MTU lower than 1500 bytes + LISP encapsulation overhead. Thanks - Fred fred.l.temp...@boeing.com [PV] How about Packet Encapsulation may exceed the MTU of the underlying physical media. To address the MTU constraints of a given physical media, the MTU of the original payload may need to be reduced or be fragmented and encapsulated in multiple packets. LISP and other tunnel types need to concern themselves with the path MTU between the tunnel ingress and egress, so it is about more than just the underlying physical media of the first hop into the tunnel. I think the wording by Brian is both clear and concise, and addresses your concerns (doesn't use may and refers to the end-to-end path). Unless there is strong objection, I will use that wording. Almost. Suggest changing Brian's wording slightly as follows: Encapsulation increases the amount of overhead associated with each packet. For LISP, this added overhead decreases the effective end-to-end path MTU. Reason is that this statement is true for LISP, but not necessarily true for all other tunnel types. I tried finding a tunneling protocol where it isn't true, but I came up empty. Can you please give an example of a tunnel where the encapsulation overhead does not result in a decrease of the E2E PMTU? Even if the subject matter is LISP, and even if there is an exception, I wouldn't single it out when *most* tunneling protocols have the same issue. -Lori Thanks - Fred fred.l.temp...@boeing.com Thanks, -Lori ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
On 05/28/2013 11:38 PM, Templin, Fred L wrote: -Original Message- From: Paul Vinciguerra [mailto:pvi...@vinciconsulting.com] Sent: Tuesday, May 28, 2013 12:58 PM To: Templin, Fred L; Lori Jakab; Brian Haberman Cc: draft-ietf-lisp-deploym...@tools.ietf.org; lisp@ietf.org Subject: RE: [lisp] AD Evaluation: draft-ietf-lisp-deployment Encapsulation results in an end-to-end path MTU of less than 1500 bytes, if encapsulated packets need to travel over links with MTU lower than 1500 bytes + LISP encapsulation overhead. Thanks - Fred fred.l.temp...@boeing.com [PV] How about Packet Encapsulation may exceed the MTU of the underlying physical media. To address the MTU constraints of a given physical media, the MTU of the original payload may need to be reduced or be fragmented and encapsulated in multiple packets. LISP and other tunnel types need to concern themselves with the path MTU between the tunnel ingress and egress, so it is about more than just the underlying physical media of the first hop into the tunnel. I think the wording by Brian is both clear and concise, and addresses your concerns (doesn't use may and refers to the end-to-end path). Unless there is strong objection, I will use that wording. Thanks, -Lori ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
Hi Lori, -Original Message- From: Lori Jakab [mailto:lja...@ac.upc.edu] Sent: Wednesday, May 29, 2013 9:58 AM To: Templin, Fred L Cc: Paul Vinciguerra; Lori Jakab; Brian Haberman; draft-ietf-lisp- deploym...@tools.ietf.org; lisp@ietf.org Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment On 05/28/2013 11:38 PM, Templin, Fred L wrote: -Original Message- From: Paul Vinciguerra [mailto:pvi...@vinciconsulting.com] Sent: Tuesday, May 28, 2013 12:58 PM To: Templin, Fred L; Lori Jakab; Brian Haberman Cc: draft-ietf-lisp-deploym...@tools.ietf.org; lisp@ietf.org Subject: RE: [lisp] AD Evaluation: draft-ietf-lisp-deployment Encapsulation results in an end-to-end path MTU of less than 1500 bytes, if encapsulated packets need to travel over links with MTU lower than 1500 bytes + LISP encapsulation overhead. Thanks - Fred fred.l.temp...@boeing.com [PV] How about Packet Encapsulation may exceed the MTU of the underlying physical media. To address the MTU constraints of a given physical media, the MTU of the original payload may need to be reduced or be fragmented and encapsulated in multiple packets. LISP and other tunnel types need to concern themselves with the path MTU between the tunnel ingress and egress, so it is about more than just the underlying physical media of the first hop into the tunnel. I think the wording by Brian is both clear and concise, and addresses your concerns (doesn't use may and refers to the end-to-end path). Unless there is strong objection, I will use that wording. Almost. Suggest changing Brian's wording slightly as follows: Encapsulation increases the amount of overhead associated with each packet. For LISP, this added overhead decreases the effective end-to-end path MTU. Reason is that this statement is true for LISP, but not necessarily true for all other tunnel types. Thanks - Fred fred.l.temp...@boeing.com Thanks, -Lori ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
Hi Lori, On 5/27/13 1:06 PM, Lori Jakab wrote: 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. I think that is still confusing for the point you are trying to get across. If encapsulation is used, it reduces the path MTU, period. Does this text capture your intent? Encapsulation increases the amount of overhead associated with each packet. This added overhead decreases the effective end-to-end path MTU. * 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. If it is removable, I would suggest taking it out. 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. I would assume that such a reference would be normative, which would result in this document be held by the RFC Editor until the referenced document was published. Is there a reason to build *another* protocol to do NAT signaling when the IETF is standardizing PCP? 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. The above seems reasonable. Should we explain the features themselves in more detail as well? A clear, concise description of the features would be good. 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. Such a note would be good to avoid confusion. 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. I think the above explanation could be tuned and used in the document. 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. But, it does not say may lead to a decrease, it says will slowly decrease the need... and that sounds like a definitive claim. 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).
Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
Hi Lori, -Original Message- From: lisp-boun...@ietf.org [mailto:lisp-boun...@ietf.org] On Behalf Of Lori Jakab Sent: Monday, May 27, 2013 10:06 AM To: Brian Haberman Cc: draft-ietf-lisp-deploym...@tools.ietf.org; lisp@ietf.org Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment 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. Encapsulation always results in a decrease in MTU, so may result does not seem accurate. A truer statement would be something like: Encapsulation results in an end-to-end path MTU of less than 1500 bytes, if encapsulated packets need to travel over links with MTU lower than 1500 bytes + LISP encapsulation overhead. Thanks - Fred fred.l.temp...@boeing.com 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
Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
-Original Message- From: Paul Vinciguerra [mailto:pvi...@vinciconsulting.com] Sent: Tuesday, May 28, 2013 12:58 PM To: Templin, Fred L; Lori Jakab; Brian Haberman Cc: draft-ietf-lisp-deploym...@tools.ietf.org; lisp@ietf.org Subject: RE: [lisp] AD Evaluation: draft-ietf-lisp-deployment Encapsulation results in an end-to-end path MTU of less than 1500 bytes, if encapsulated packets need to travel over links with MTU lower than 1500 bytes + LISP encapsulation overhead. Thanks - Fred fred.l.temp...@boeing.com [PV] How about Packet Encapsulation may exceed the MTU of the underlying physical media. To address the MTU constraints of a given physical media, the MTU of the original payload may need to be reduced or be fragmented and encapsulated in multiple packets. LISP and other tunnel types need to concern themselves with the path MTU between the tunnel ingress and egress, so it is about more than just the underlying physical media of the first hop into the tunnel. Thanks - Fred ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
[lisp] AD Evaluation: draft-ietf-lisp-deployment
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
