Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations
draft-ietf-lisp-deployment-12

[Ballot comment]
Thanks to the authors for the considerable time and effort put in to address my Discuss and Comments.

A much improved version of an important draft.

[Ballot comment]
I have updated this Comment for revision 11 (with further update after other changes were pointed out to me).

---

Section 5.1

  For sites wishing to go LISP with their PI prefix the least
  disruptive way is to upgrade their border routers to support LISP,
  register the prefix into the LISP mapping system, but keep announcing
  it with BGP as well.  This way LISP sites will reach them over LISP,
  while legacy sites will be unaffected by the change.  The main
  disadvantage of this approach is that no decrease in the DFZ routing
  table size is achieved.

True. But surely a LISP site doesn't really care about the size of the
DFZ?

# Here we discussed whether the LISP site is a transit site seeing the
# whole BGP routing table, or is an edge site. I had assumed the latter
# and so I assumed that the size of the DFZ is not important.

I think this may be symptomatic of something that shows in my comment on
cost/benefit: I see no clear distinction being made between the
motivations for customer sites and for service providers. The deployment
choice will either be forced by the service provider, or must offer the
customer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part of
the provider's network.

# Again the discussion resolved to me saying that this is not about
# *whether* to deploy LISP, but about which deployment model to
# select. Again it is about cost/benefit of the different deployment
# models.

[Ballot comment]
I have updated this Comment for revision 11.

---

I have not made this point a Discuss. I believe that if you address it
you will make the document substantially better and more useful to LISP
deployers, but my concern for the document to be made better does not
prevent publication in its current form. I do hope, however, that you
will address it.

I think that a fundamental purpose of this document is to help network
operators understand the motivation for deployment in each possible
deployment scenario. In short: What are the costs and the benefits? Who
stands to gain, and who will pay a cost?

For example, in examining Section 2.1, it seems to me that there are
considerable benefits to the network provider, while the customer does
not get anything substantial that they don't already have. On the other
hand, it appears that it is the customer who would carry the cost of
this deployment approach.

# In email Lori noted
#
# That depends if it is the network provider who manages the CPE (like
# residential cable/DSL), or it is the customer.  In the former case, it
# is the ISP that has to upgrade all devices, and it may not be in its
# best interest.  If it is the customer managing the router, the ISP
# still doesn't get too many benefits IMO.
#
# ...and I suggested including some text like this.

On the other hand, the approach in Section 2.2 places the cost with the
carrier. In this deployment it looks like the carrier gets quite a lot
of benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. I
know there is some text (especially in sections 2.1 and 2.2) that goes
over some of the pluses and minuses, but I don't see a crisp analysis of
the cost/benefit for the different deployment models.

# To expand on this Comment as per our email exchange...
#
# I was not looking for a detailed cost-benefit.
# Nor was I looking for "why deploy LISP".
# You have suggested a few different deployment models in your
# document.
# Suppose I was trying to select the right model for my network
# (having already decided that LISP tastes very nice and will bring
# up the shine on my floor quite nicely), could your document help
# me with a summary of "this model is good for foo, but bad for
# bar"? Do the benefits/disadvantages show predominantly for
# the network provider or the network user?
#
# Lori also suggested...
#
# Would a new section like section 2.6 help?
# Or extending section 2.6?
#
# ...and I replied
#
# You could handle this one of three ways.
# 1. Add text to each of 2.1 through 2.4 to show the pros and
#  cons.
# 2. Extend 2.6 to collect together the text from 1. (This might
#  allow you to also explain the key benefits of LISP without
#  repeating yourself)
# 3. Add a new section per 2.

---

Section 5.1

  For sites wishing to go LISP with their PI prefix the least
  disruptive way is to upgrade their border routers to support LISP,
  register the prefix into the LISP mapping system, but keep announcing
  it with BGP as well.  This way LISP sites will reach them over LISP,
  while legacy sites will be unaffected by the change.  The main
  disadvantage of this approach is that no decrease in the DFZ routing
  table size is achieved.

True. But surely a LISP site doesn't really care about the size of the
DFZ?

# Here we discussed whether the LISP site is a transit site seeing the
# whole BGP routing table, or is an edge site. I had assumed the latter
# and so I assumed that the size of the DFZ is not important.

I think this may be symptomatic of something that shows in my comment on
cost/benefit: I see no clear distinction being made between the
motivations for customer sites and for service providers. The deployment
choice will either be forced by the service provider, or must offer the
customer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part of
the provider's network.

# Again the discussion resolved to me saying that this is not about
# *whether* to deploy LISP, but about which deployment model to
# select. Again it is about cost/benefit of the different deployment
# models.

[Ballot comment]
I have updated this Comment for revision 11.

---

I have not made this point a Discuss. I believe that if you address it
you will make the document substantially better and more useful to LISP
deployers, but my concern for the document to be made better does not
prevent publication in its current form. I do hope, however, that you
will address it.

I think that a fundamental purpose of this document is to help network
operators understand the motivation for deployment in each possible
deployment scenario. In short: What are the costs and the benefits? Who
stands to gain, and who will pay a cost?

For example, in examining Section 2.1, it seems to me that there are
considerable benefits to the network provider, while the customer does
not get anything substantial that they don't already have. On the other
hand, it appears that it is the customer who would carry the cost of
this deployment approach.

# In email Lori noted
#
# That depends if it is the network provider who manages the CPE (like
# residential cable/DSL), or it is the customer.  In the former case, it
# is the ISP that has to upgrade all devices, and it may not be in its
# best interest.  If it is the customer managing the router, the ISP still
# doesn't get too many benefits IMO.
#
# ...and I suggested including some text like this.

On the other hand, the approach in Section 2.2 places the cost with the
carrier. In this deployment it looks like the carrier gets quite a lot
of benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. I
know there is some text (especially in sections 2.1 and 2.2) that goes
over some of the pluses and minuses, but I don't see a crisp analysis of
the cost/benefit for the different deployment models.

# To expand on this Comment as per our email exchange...
#
# I was not looking for a detailed cost-benefit.
# Nor was I looking for "why deploy LISP".
# You have suggested a few different deployment models in your document.
# Suppose I was trying to select the right model for my network (having already
# decided that LISP tastes very nice and will bring up the shine on my floor quite
# nicely), could your document help me with a summary of "this model is good for
# foo, but bad for bar"? Do the benefits/disadvantages show predominantly for
# the network provider or the network user?
#
# Lori also suggested...
#
# Would a new section like section 2.6 help?  Or extending section 2.6?
#
# ...and I replied
#
# You could handle this one of three ways.
# 1. Add text to each of 2.1 through 2.4 to show the pros and cons.
# 2. Extend 2.6 to collect together the text from 1. (This might allow you
#  to also explain the key benefits of LISP without repeating yourself)
# 3. Add a new section per 2.

---

Section 5.1

  For sites wishing to go LISP with their PI prefix the least
  disruptive way is to upgrade their border routers to support LISP,
  register the prefix into the LISP mapping system, but keep announcing
  it with BGP as well.  This way LISP sites will reach them over LISP,
  while legacy sites will be unaffected by the change.  The main
  disadvantage of this approach is that no decrease in the DFZ routing
  table size is achieved.

True. But surely a LISP site doesn't really care about the size of the
DFZ?

# Here we discussed whether the LISP site is a transit site seeing the
# whole BGP routing table, or is an edge site. I had assumed the latter
# and so I assumed that the size of the DFZ is not important.

I think this may be symptomatic of something that shows in my comment on
cost/benefit: I see no clear distinction being made between the
motivations for customer sites and for service providers. The deployment
choice will either be forced by the service provider, or must offer the
customer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part of
the provider's network.

# Again the discussion resolved to me saying that this is not about *whether*
# to deploy LISP, but about which deployment model to select. Again it is
# about cost/benefit of the different deployment models.

[Ballot discuss]
Thanks for this document. I think it is critical for the next steps with
LISP for people to understand the deployment options, benefits, and
costs. I hope we can polish this document to make it more helpful to
network operators in explaining how they can choose between the
different deployment models.

This Discuss has been updated for revision 11. Points that have been
addressed have been removed. New text is prefixed '#'

Thanks for the work so far.

---

This issue is border-line Discuss/Comment, but it is actionable, and it
is a matter of clarity and interaction with other documents, so I think
it is worth handling as a Discuss.

You are, I think, free to define terms for use within the scope of this
document, and given the title of the document, a clear definition of
"network element" is important.  However, where Section 1 says...

  We formally define the following two terms:

  Network element:  Active or passive device that is connected to other
      active or passive devices for transporting packet switched data.

... I think you need to explicitly scope the definition to this
document.  The point here is that "network element" is an extremely
widely used term. It even has its own Wikipedia entry. And, sadly, the
common usage is not that close to the definition you have here (although
maybe you have defined a subset of the common usage). I think it is
important that you carefully disambiguate the term from the normal
meaning and set your scope to "within the document we define..."

As an aside, your current definition does not include end-systems. That
is nodes that source or consume packets since they do not "transport" see
those packets.  Thus the definition of LISP Site as "A single host or a
set of network elements" does not seem to allow for "a set of hosts and
network elements".

# In an email thread, Lori proposed to change to
#
# Network element:  facility or equipment used in the provision of a
# communications service over the Internet.
#
# I don't see that change. Maybe also including a citation for the
# definition would be helpful.

---

It seems that there is a missing piece of discussion about what happens
when an ETR operator advertises stuff it shouldn't (e.g., to attract
traffic). This is policeable, but the policing function is a critical
part of the deployment model. It needs to be described.

The nearest discussion I could find to this was in 5.3, but it doesn't
go close to talking about the problem.

Of course, a chunk of this could easily be argued to be an operational
discussion that belongs in a separate document.  I'd be OK with that, on
the whole, but there are surely some deployment considerations as well.
Which model is best able to protect against this? What are the
deployment concerns related to this problem?

# This comment is related to an ETR operator attracting traffic by
# overclaiming an EID-prefix and could be handled by a forward
# reference to [I-D.ietf-lisp-threats]  (Section 4.4.3).

[Ballot comment]
I have updated this Comment for revision 11.

---

I have not made this point a Discuss. I believe that if you address it
you will make the document substantially better and more useful to LISP
deployers, but my concern for the document to be made better does not
prevent publication in its current form. I do hope, however, that you
will address it.

I think that a fundamental purpose of this document is to help network
operators understand the motivation for deployment in each possible
deployment scenario. In short: What are the costs and the benefits? Who
stands to gain, and who will pay a cost?

For example, in examining Section 2.1, it seems to me that there are
considerable benefits to the network provider, while the customer does
not get anything substantial that they don't already have. On the other
hand, it appears that it is the customer who would carry the cost of
this deployment approach.

# In email Lori noted
#
# That depends if it is the network provider who manages the CPE (like
# residential cable/DSL), or it is the customer.  In the former case, it
# is the ISP that has to upgrade all devices, and it may not be in its
# best interest.  If it is the customer managing the router, the ISP still
# doesn't get too many benefits IMO.
#
# ...and I suggested including some text like this.

On the other hand, the approach in Section 2.2 places the cost with the
carrier. In this deployment it looks like the carrier gets quite a lot
of benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. I
know there is some text (especially in sections 2.1 and 2.2) that goes
over some of the pluses and minuses, but I don't see a crisp analysis of
the cost/benefit for the different deployment models.

# To expand on this Comment as per our email exchange...
#
# I was not looking for a detailed cost-benefit.
# Nor was I looking for "why deploy LISP".
# You have suggested a few different deployment models in your document.
# Suppose I was trying to select the right model for my network (having already
# decided that LISP tastes very nice and will bring up the shine on my floor quite
# nicely), could your document help me with a summary of "this model is good for
# foo, but bad for bar"? Do the benefits/disadvantages show predominantly for
# the network provider or the network user?
#
# Lori also suggested...
#
# Would a new section like section 2.6 help?  Or extending section 2.6?
#
# ...and I replied
#
# You could handle this one of three ways.
# 1. Add text to each of 2.1 through 2.4 to show the pros and cons.
# 2. Extend 2.6 to collect together the text from 1. (This might allow you
#  to also explain the key benefits of LISP without repeating yourself)
# 3. Add a new section per 2.

---

Section 5.1

  For sites wishing to go LISP with their PI prefix the least
  disruptive way is to upgrade their border routers to support LISP,
  register the prefix into the LISP mapping system, but keep announcing
  it with BGP as well.  This way LISP sites will reach them over LISP,
  while legacy sites will be unaffected by the change.  The main
  disadvantage of this approach is that no decrease in the DFZ routing
  table size is achieved.

True. But surely a LISP site doesn't really care about the size of the
DFZ?

# Here we discussed whether the LISP site is a transit site seeing the
# whole BGP routing table, or is an edge site. I had assumed the latter
# and so I assumed that the size of the DFZ is not important.

I think this may be symptomatic of something that shows in my comment on
cost/benefit: I see no clear distinction being made between the
motivations for customer sites and for service providers. The deployment
choice will either be forced by the service provider, or must offer the
customer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part of
the provider's network.

# Again the discussion resolved to me saying that this is not about *whether*
# to deploy LISP, but about which deployment model to select. Again it is
# about cost/benefit of the different deployment models.

[Ballot comment]
Thank you for a well-written and useful document!

A few comments:

Shouldn't Section 2.6 table include the NAT case as well?

I'd probably place a stronger warning on the recursive deployment case. My personal experience is that recursive encapsulation models are not very practical, particularly when something goes wrong and debugging is needed.

>  For more details on P-ETRs see the [RFC6832] draft.

s/draft//

I agree with Stephen that the document needs to be clearer about the lack of currently specified security support, and what the implications of that are.

[Ballot comment]
Just one comment ... I'm confused about the Abstract

  This document is a snapshot of different Locator/Identifier
  Separation Protocol (LISP) deployment scenarios.  It discusses the
  placement of new network elements introduced by the protocol,
  representing the thinking of the authors as of Summer 2013.  LISP
  deployment scenarios may have evolved since.  This memo represents
  one stable point in that evolution of understanding.

Is "the thinking of the authors" still an accurate description? I'm only asking because the draft name indicates that it was adopted by the working group, and the shepherd write-up says "The document shepherd believes that there was a clear consensus for publishing the draft as informational RFC", which I could read as "consensus that we think this" or "consensus that it's valuable to publish that some people think this".

I didn't see any reference to this except in the Abstract, so I thought I'd ask.

[Ballot discuss]
At this point, I think you need to add a deployment consideration along the lines of "There is no standardized security to implement.  Beware that there are no counter measures for any of the threats identified in [I-D.ietf-lisp-threats]."  I'm basing this on the long expired [I-D.ietf-lisp-sec] draft.  Maybe I'm wrong (and I hope I am).

[I-D.ietf-lisp-sec] appears to rely on manual key management.  What consideration has been given to the frequency with which the keys authentication keys should be changed?

[Ballot discuss]
Thanks for this document. I think it is critical for the next steps with
LISP for people to understand the deployment options, benefits, and
costs. I hope we can polish this document to make it more helpful to
network operators in explaining how they can choose between the
different deployment models.

---

This issue is border-line Discuss/Comment, but it is actionable, and it
is a matter of clarity and interaction with other documents, so I think
it is worth handling as a Discuss.

You are, I think, free to define terms for use within the scope of this
document, and given the title of the document, a clear definition of
"network element" is important.  However, where Section 1 says...

  We formally define the following two terms:

  Network element:  Active or passive device that is connected to other
      active or passive devices for transporting packet switched data.

... I think you need to explicitly scope the definition to this
document.  The point here is that "network element" is an extremely
widely used term. It even has its own Wikipedia entry. And, sadly, the
common usage is not that close to the definition you have here (although
maybe you have defined a subset of the common usage). I think it is
important that you carefully disambiguate the term from the normal
meaning and set your scope to "within the document we define..."

As an aside, your current definition does not include end-systems. That
is nodes that source or consume packets since they do not "transport"
those packets.  Thus the definition of LISP Site as "A single host or a
set of network elements" does not seem to allow for "a set of hosts and
network elements".

---

I tried to correlate the LISP features shown in Section 2.6 with the
applications detailed in draft-ietf-lisp-introduction.  In the latter I
found 7 principal applications (section 5) of which just one (Traffic
Engineering) appears in Section 2.6 of this document.

There are several possibilities here:
- I may be misunderstanding the terms used so that there is actually a
  larger overlap than I am seeing (in which case some alignment of terms
  would be handy)
- It might not be appropriate to compare the lists (which you could
  explain to me in an email, and might result in a little text to
  clarify the context of 2.6)
- draft-ietf-lisp-introduction may be at a really early stage and so it
  would be appropriate to update *that* document to be in synch with
  this one.
- There may be some discussion of other features missing from this
  document.

---

The Recursive Deployment Model

Reading Section 2.4 I found the recursive deployment model burried in
the text.  I think that this is an important model that is mentioned in
several other documents and adds quite a lot of function for the
operator. So I believe that you should have a separate section
specifically for the recursive model.

(Note that even the table in Section 2.6 acknowledges the recursive model
as a deployment model.)

In particular how is the recursive model deployed, what are the
identifiers and what are the locators?

Perhaps a picture, too.

But this did raise for me the question of "Deployment Model or
Functional Model?"  Clearly Sections 2.1, 2.2, and 2.3 are deployment
models.  Similarly, a new section on the Recursive Model would be about
a deployment model. But the current Section 2.4 seems to be a functional
model, not a deployment model.

It would be helpful to separate deployment models from functional models
within the document. 

---

Section 2.5

I don't understand what happens when there is not enough global address
space for EIDs.  The same question for RLOCs.  And what if there is not
enough global address space for *both* EIDs and RLOCs?

Even if there is a simple answer to this question, it would be nice to
add a couple of lines to make it a bit easier for the deployer.

---

Root Operators

Section 3.1 seems to make a statement that DDT-like operation is to be
used to the exclusion of ALT.  I don't (particularly) have a problem
with that, although it would be nice if this document was far clearer
about advising on the selection between these two modes.

  Participation in the mapping
  database, and the storing of EID-to-RLOC mapping data is subject to
  the policies of the "root" operators, who should check ownership
  rights for the EID prefixes stored in the database by participants.
  These policies are out of the scope of this document.

But I think there is quite a chunk missing in the document about what a
"root operator" is in the LISP context. In particular, how will a root
operator be selected in such deployments?

There is a tiny mention of this in Section 3.2, but surely this is a
major issue for deployment.  How does a root get selected, how is it
governed, what are the administrative policies, how is it funded? How
do you make sure there is only one root (if that is a requirement)?

---

It seems that there is a missing piece of discussion about what happens
when an ITR operator advertises stuff it shouldn't (e.g., to attract
traffic). This is policeable, but the policing function is a critical
part of the deployment model. It needs to be described.

The nearest discussion I could find to this was in 5.3, but it doesn't
go close to talking about the problem.

Of course, a chunk of this could easily be argued to be an operational
discussion that belongs in a separate document.  I'd be OK with that, on
the whole, but there are surely some deployment considerations as well.
Which model is best able to protect against this? What are the
deployment concerns related to this problem?

[Ballot comment]
I have not made this point a Discuss. I believe that if you address it
you will make the document substantially better and more useful to LISP
deployers, but my concern for the document to be made better does not
prevent publication in its current form. I do hope, however, that you
will address it.

I think that a fundamental purpose of this document is to help network
operators understand the motivation for deployment in each possible
deployment scenario. In short: What are the costs and the benefits? Who
stands to gain, and who will pay a cost?

For example, in examining Section 2.1, it seems to me that there are
considerable benefits to the network provider, while the customer does
not get anything substantial that they don't already have. On the other
hand, it appears that it is the customer who would carry the cost of
this deployment approach.

On the other hand, the approach in Section 2.2 places the cost with the
carrier. In this deployment it looks like the carrier gets quite a lot
of benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. I
know there is some text (especially in sections 2.1 and 2.2) that goes
over some of the pluses and minuses, but I don't see a crisp analysis of
the cost/benefit for the different deployment models.

---

Section 1

  this document is intended as a
  guide for the operational community for LISP deployments in their
  networks.  It is expected to evolve as LISP deployment progresses,
  and the described scenarios are better understood or new scenarios
  are discovered.

What is the "evolution" here? Do you expect to revise this RFC? That
would be fine.  Maybe just say so.

---

Section 1

  This experimental specification has areas that require additional
  experience and measurement.  It is NOT RECOMMENDED for deployment
  beyond experimental situations.  Results of experimentation may lead
  to modifications and enhancements of protocol mechanisms defined in
  this document.  See Section 15 [of RFC 6830] for specific, known
  issues that are in need of further work during development,
  implementation, and experimentation.

Thank you for including this paragraph.
Maybe some wordsmithing since this is not actually a specification
containing protocol mechanisms.

Perhaps...

  This experimental document describing deployment considerations and
  the LISP specifications have areas that require additional experience
  and measurement.  LISP is NOT RECOMMENDED for deployment beyond
  experimental situations.  Results of experimentation may lead
  to modifications and enhancements of the LISP protocol mechanisms.
  See Section 15 [of RFC 6830] for specific, known issues that are in
  need of further work during development, implementation, and
  experimentation.

---

A picture would be really nice in Section 2.5.  It took a lot of reading
and rereading (and in fact I had to sketch some figures) to work out
where the NATs are.

---

Section 5.1

  For sites wishing to go LISP with their PI prefix the least
  disruptive way is to upgrade their border routers to support LISP,
  register the prefix into the LISP mapping system, but keep announcing
  it with BGP as well.  This way LISP sites will reach them over LISP,
  while legacy sites will be unaffected by the change.  The main
  disadvantage of this approach is that no decrease in the DFZ routing
  table size is achieved.

True. But surely a LISP site doesn't really care about the size of the
DFZ?

I think this may be symptomatic of something that shows in my comment on
cost/benefit: I see no clear distinction being made between the
motivations for customer sites and for service providers. The deployment
choice will either be forced by the service provider, or must offer the
customer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part of
the provider's network.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-lisp-deployment-08, which is currently
in Last Call, and has the following comment from the IANA reviewer
team:

We understand that, upon approval of this document, there are no
IANA Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (LISP Network Element Deployment Considerations) to Informational RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP Network Element Deployment Considerations'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-07-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document discusses the different scenarios for the deployment of
  the new network elements introduced by the Locator/Identifier
  Separation Protocol (LISP).




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-lisp-deployment/ballot/


No IPR declarations have been submitted directly on this I-D.

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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The draft is intended to be an informational RFC as indicated in the title page header. In fact, the draft describes how to deploy network elements (active/passive device(s) connected to other active/passive device(s) for transporting packet switched data) introduced by the Locator/Identifier Separation Protocol (LISP). Each subsection of the draft considers an element type and discusses the impact of deployment scenarios on the protocol specification.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:



Technical Summary:

LISP is a protocol which can be used for different purposes. This draft describes how to deploy its associated network elements, in order to identify possible deployment scenarios and the additional requirements they may impose on the protocol specification and other protocols. This document is intended as a guide for the operational community for LISP deployments in their networks and is expected to evolve as LISP deployment progresses, and the described scenarios are better understood or new scenarios are discovered.




Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

There was no controversy nor any contentious issues during the WG process. The consensus was not rough and the draft came out as the result of a collective effort.



Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

There are multiple implementations of the protocol that am aware of. To my knowledge, at least one vendor has implemented the specification. The draft has received a fair amount of reviews and discussions without triggering any major change(s) in the document nor substantive issue(s).



Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

- Document Shepherd: Wassim Haddad (Wassim.Haddad@ericsson.com)

- Responsible Area Director: Brian Haberman (INTERNET Area Director)



(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has reviewed the draft for completeness and believes that it is ready in its current form for publication as informational standard. There is one nit in Section 1, Network element definition: "connected" is repeated twice



(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document shepherd does not have any concern about the depth or breadths of the reviews.



(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The security implications are addressed in a separated document (work in progress). Other portions do not need review from particular or broader perspective.



(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The document shepherd does not have any specific concerns or issues with the document.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

The document shepherd has sent an email on Saturday 04/27 and received within 48 hours confirmations from two co-authors that they are not aware of any IPR disclosures.



(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure which references this document has been filed.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document shepherd believes that there was a clear consensus for publishing the draft as informational RFC. LISP WG chairs asked for consensus during the LISP WG session then again on the ML.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

The document shepherd is not aware of any threats nor animosity nor extreme discontent with regards to publishing the draft as informational RFC.



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Line 487 has weird spacing: '…infrastructure  x  ...'


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document does not require reviews related to MIB and does not make any request to IANA.



(13) Have all references within this document been identified as either normative or informative?

Yes, all references have been identified in both categories. In addition to citing internet-drafts and RFCs, Informative references section mention an academic paper.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is no ambiguity related to Normative references. The corresponding section cites 3 RFCs.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The publication of this document will not change the status of any existing RFCs.



(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The document makes no request to IANA.



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document does not have IANA registries that require expert review for future allocations.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

Document shepherd has reviewed all sections. No formal language