Subject: [lisp] AD Evaluation: draft-ietf-lisp-deployment

From: Brian Haberman <[email-masked]>
Date: Tue, 14 May 2013 13:37:03 -0400

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 28 May 2013 09:59:57 -0400

Hi Lori,

On 5/27/13 1:06 PM, Lori Jakab wrote:
> 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."

> We don't object to removing the bullet referencing the draft.
>

If it is removable, I would suggest taking it out.

> 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?

> 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.

> 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.

> 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.

> 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.

> We will remove the last sentence of the second paragraph.
>
>>
>> 15. Section 5.4
>>
> 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.
>

If that is the case, then the text should say that the only focus was on 
DFZ route table size and that other factors were not considered.

> 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.

I don't think you have to discuss them in detail, but it would be 
worthwhile to say that these other metrics may be impacted, but have not 
been measured as of yet.

>
> 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?
>

If one is warranted, it is a possibility.  Another approach would be for 
the academics involved to do those studies and publish them.

> 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?
>

I think it is more suitable as an appendix.  Make sure there is some 
descriptive lead-in text.  That intro should explicitly state that the 
appendix is informative in nature.

> 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.
>
>>
> They are offered by the LISP pilot network, and are intended to be kept
> stable.  However, we don't object to removing that sentence.
>

The trade-off here is that the use of URLs is discouraged by the RFC 
Editor (https://www.rfc-editor.org/policy.html#policy.urls).  The 
authors need to determine if the inclusion of a reference is beneficial 
enough to the document that they are willing to argue for its inclusion.

Regards,
Brian

---

From: Lori Jakab <[email-masked]>
Date: Mon, 27 May 2013 20:06:27 +0300

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.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 May 2013 20:01:25 +0000

Hi Lori,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lori Jakab
> Sent: Monday, May 27, 2013 10:06 AM
> To: Brian Haberman
> Cc: [email-masked]; [email-masked]
> Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment
> 
> Hi Brian, all,
> 

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
[email-masked]

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Paul Vinciguerra <[email-masked]>
Date: Tue, 28 May 2013 19:58:05 +0000

> [email-masked]

[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."

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 May 2013 20:38:56 +0000

> From: Paul Vinciguerra [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2013 12:58 PM
> To: Templin, Fred L; Lori Jakab; Brian Haberman
> Subject: RE: [lisp] AD Evaluation: draft-ietf-lisp-deployment
> 
> >
> "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

---

From: Lori Jakab <[email-masked]>
Date: Wed, 29 May 2013 19:57:33 +0300

> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 May 2013 17:32:14 +0000

Hi Lori,

> From: Lori Jakab [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2013 9:58 AM
> To: Templin, Fred L
> Cc: Paul Vinciguerra; Lori Jakab; Brian Haberman; draft-ietf-lisp-
> [email-masked]; [email-masked]

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

---

From: Lori Jakab <[email-masked]>
Date: Thu, 30 May 2013 16:14:40 +0300

Hi Fred,

> 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

---

From: Lori Jakab <[email-masked]>
Date: Thu, 30 May 2013 16:30:17 +0300

Hi Brian,

On 05/28/2013 04:59 PM, Brian Haberman wrote:
> across.  If encapsulation is used, it reduces the path MTU, period.
> Does this text capture your intent?
>

It captures it very well, thank you.

[...]

> document was published.  

That's why we didn't include it, it is still an individual submission. 
I will mention PCP as a potential alternative, and not mention this draft.

> Is there a reason to build *another* protocol to do NAT signaling when
> the IETF is standardizing PCP?

I wasn't aware of the PCP standardization effort, and I'm not sure if
the authors of the draft mentioned above were.  I haven't fully read the
protocol, I'm not sure if it would cover all the necessities of LISP. 
draft-ermagan-lisp-nat-traversal was designed for tight integration with
LISP.

[...]

> decrease the need..." and that sounds like a definitive claim.

Would s/will/may/ resolve your concern?

[...]

We will send a diff with all the changes soon.

Thanks,
-Lori

---

From: Brian Haberman <[email-masked]>
Date: Thu, 30 May 2013 09:53:00 -0400

> I will mention PCP as a potential alternative, and not mention this draft.

Ok.

> draft-ermagan-lisp-nat-traversal was designed for tight integration with

I have yet to review that individual draft, but it is possible they are 
re-inventing the wheel (STUN, PCP, UPnP, etc.).

> Would s/will/may/ resolve your concern?

How about "may decrease the need"?  That way, you don't have to leave 
the reader wondering about the speed of the possible reduction.

Regards,
Brian

---

From: Lori Jakab <[email-masked]>
Date: Thu, 30 May 2013 17:01:16 +0300

> the reader wondering about the speed of the possible reduction.

Sounds good, thank you.

Regards,
-Lori

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 May 2013 15:22:27 +0000

Hi Lori,

> Sent: Thursday, May 30, 2013 6:15 AM
> To: Templin, Fred L
> Cc: [email-masked]
> >>>> MTU of the original payload may need to be reduced or be
> fragmented
> >> and

SEAL is an example of a tunnel type where the added overhead does
not decrease the effective end-to-end path MTU for MTUs up to 1500
bytes. Another example is CAPWAP. So, maybe say:

  "For LISP and many other tunnel types, this added overhead decreases
  the effective end-to-end path MTU."

Thanks - Fred

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 30 May 2013 08:27:12 -0700

> I have yet to review that individual draft, but it is possible they are re-inventing the wheel (STUN, PCP, UPnP, etc.).

The NAT-traversal document is also providing optimal RTR placement for a roaming node. Yes, the RTR needs to know the translated address so a simplification of STUN et al is provided, but that is only a very small subset of the complete proposal.

Dino