IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup

2014-02-14

12

Cindy Morgan

IESG has approved the document

2014-02-14

12

Cindy Morgan

Closed "Approve" ballot

2014-02-14

12

Cindy Morgan

Ballot approval text was generated

2014-02-14

12

Brian Haberman

Ballot writeup was changed

2014-02-14

12

Brian Haberman

Ballot approval text was generated

2014-02-12

12

Adrian Farrel

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

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

2014-02-12

12

Adrian Farrel

[Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss

2014-01-17

12

Lorand Jakab

New version available: draft-ietf-lisp-deployment-12.txt

2014-01-03

11

Adrian Farrel

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

---

Section 5.1

...

[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 themotivations for customer sites and for service providers. The deploymentchoice will either be forced by the service provider, or must offer thecustomer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part ofthe 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.

2014-01-03

11

Adrian Farrel

Ballot comment text updated for Adrian Farrel

2014-01-01

11

Sean Turner

[Ballot comment]Thanks for addressing my concerns.

Happy New Year.

2014-01-01

11

Sean Turner

[Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss

2013-12-30

11

Adrian Farrel

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

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

---

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

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

For example, in examining Section 2.1, it seems to me that there areconsiderable benefits to the network provider, while the customer does not get anything substantial that they don't already have. On the otherhand, 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 thecarrier. In this deployment it looks like the carrier gets quite a lotof benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. Iknow 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 ofthe 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 themotivations for customer sites and for service providers. The deploymentchoice will either be forced by the service provider, or must offer thecustomer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part ofthe 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.

2013-12-30

11

Adrian Farrel

Ballot comment text updated for Adrian Farrel

2013-12-30

11

Adrian Farrel

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

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

---

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

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

For example, in examining Section 2.1, it seems to me that there areconsiderable benefits to the network provider, while the customer does not get anything substantial that they don't already have. On the otherhand, 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 thecarrier. In this deployment it looks like the carrier gets quite a lotof benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. Iknow 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 ofthe 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 themotivations for customer sites and for service providers. The deploymentchoice will either be forced by the service provider, or must offer thecustomer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part ofthe 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.

2013-12-30

11

Adrian Farrel

Ballot comment text updated for Adrian Farrel

2013-12-30

11

Adrian Farrel

[Ballot discuss]Thanks for this document. I think it is critical for the next steps withLISP for people to understand the deployment options, benefits ...

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

This Discuss has been updated for revision 11. Points that have beenaddressed 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 itis a matter of clarity and interaction with other documents, so I thinkit is worth handling as a Discuss.

You are, I think, free to define terms for use within the scope of thisdocument, 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, thecommon usage is not that close to the definition you have here (althoughmaybe you have defined a subset of the common usage). I think it isimportant 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. Thatis 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 aset of network elements" does not seem to allow for "a set of hosts andnetwork 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 happenswhen an ETR operator advertises stuff it shouldn't (e.g., to attracttraffic). This is policeable, but the policing function is a criticalpart of the deployment model. It needs to be described.

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

Of course, a chunk of this could easily be argued to be an operationaldiscussion that belongs in a separate document. I'd be OK with that, onthe whole, but there are surely some deployment considerations as well.Which model is best able to protect against this? What are thedeployment 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).

2013-12-30

11

Adrian Farrel

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

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

---

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

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

For example, in examining Section 2.1, it seems to me that there areconsiderable benefits to the network provider, while the customer does not get anything substantial that they don't already have. On the otherhand, 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 thecarrier. In this deployment it looks like the carrier gets quite a lotof benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. Iknow 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 ofthe 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 themotivations for customer sites and for service providers. The deploymentchoice will either be forced by the service provider, or must offer thecustomer some benefit.

Perhaps the only counter to this is if the stub-AS is actually part ofthe 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.

State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation

2013-08-29

10

Jari Arkko

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

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

2013-08-29

10

Jari Arkko

[Ballot Position Update] New position, Yes, has been recorded for Jari Arkko

[Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes

2013-08-28

10

Spencer Dawkins

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

This document is a snapshot of different Locator/Identifier Separation Protocol (LISP ...

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

2013-08-28

10

Spencer Dawkins

[Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins

2013-08-28

10

Stewart Bryant

[Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant

2013-08-28

10

Sean Turner

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

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

2013-08-28

10

Sean Turner

[Ballot Position Update] New position, Discuss, has been recorded for Sean Turner

2013-08-27

10

Martin Stiemerling

[Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling

2013-08-26

10

Barry Leiba

[Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba

2013-08-24

10

Adrian Farrel

[Ballot discuss]Thanks for this document. I think it is critical for the next steps withLISP for people to understand the deployment options, benefits ...

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

---

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

You are, I think, free to define terms for use within the scope of thisdocument, 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, thecommon usage is not that close to the definition you have here (althoughmaybe you have defined a subset of the common usage). I think it isimportant 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. Thatis nodes that source or consume packets since they do not "transport"those packets. Thus the definition of LISP Site as "A single host or aset of network elements" does not seem to allow for "a set of hosts andnetwork elements".

---

I tried to correlate the LISP features shown in Section 2.6 with theapplications detailed in draft-ietf-lisp-introduction. In the latter Ifound 7 principal applications (section 5) of which just one (TrafficEngineering) 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 inseveral 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 modelas 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 deploymentmodels. Similarly, a new section on the Recursive Model would be abouta deployment model. But the current Section 2.4 seems to be a functionalmodel, not a deployment model.

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

---

Section 2.5

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

Even if there is a simple answer to this question, it would be nice toadd 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 beused to the exclusion of ALT. I don't (particularly) have a problem with that, although it would be nice if this document was far clearerabout 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 rootoperator 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 itgoverned, what are the administrative policies, how is it funded? Howdo 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 happenswhen an ITR operator advertises stuff it shouldn't (e.g., to attracttraffic). This is policeable, but the policing function is a criticalpart of the deployment model. It needs to be described.

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

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

2013-08-24

10

Adrian Farrel

[Ballot comment]I have not made this point a Discuss. I believe that if you address ityou will make the document substantially better and ...

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

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

For example, in examining Section 2.1, it seems to me that there areconsiderable benefits to the network provider, while the customer does not get anything substantial that they don't already have. On the otherhand, 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 thecarrier. In this deployment it looks like the carrier gets quite a lotof benefits, but the customer actually loses some function.

It would be really valuable for this document to tackle this head on. Iknow 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 ofthe 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? Thatwould 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 specificationcontaining 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 readingand 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 deploymentchoice will either be forced by the service provider, or must offer thecustomer some benefit.

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

2013-08-24

10

Adrian Farrel

[Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel

2013-08-23

10

Warren Kumari

Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Warren Kumari.

The IESG has received a request from the Locator/ID Separation ProtocolWG (lisp) to consider the following document:- 'LISP Network Element Deployment Considerations' <draft-ietf-lisp-deployment-08.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2013-07-15. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain thebeginning 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).

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

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

2013-05-14

07

Brian Haberman

Changed document writeup

2013-05-03

07

Brian Haberman

State changed to AD Evaluation from Publication Requested

2013-05-01

07

Terry Manderson

Changed document writeup

2013-05-01

07

Terry Manderson

Document shepherd changed to Wassim Haddad

2013-05-01

07

Cindy Morgan

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

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