Locator/ID Separation Protocol (LISP) Map-Server Interface
draft-ietf-lisp-ms-16

[Ballot discuss]
There needs to be a ref to section 15 of base in this document
and there needs to be an issues warning in the Introduction.

What I would have liked to have seen is a ref to section
5 of this draft in the introduction and a ref section 15 of
base somewhere, either in the intro or in section 5.

I note that there are a larger than normal number of no
positions on this document. My recollection was that
there was an agreement that this draft would to come
back to IESG with a cleared ballot after the base draft
had been approved, and it looks like that has not happened.

[Ballot discuss]
We are nearly there.

draft-ief-lisp-20 now contains sufficient caveats to satisfy my issue on that document.

My remaining point on this draft can be addressed wih a short piece of text and a pointer.

Please consider the text recently added to http://www.ietf.org/id/draft-ietf-lisp-map-versioning-07.txt

  Issues and concerns about the deployment of LISP for Internet traffic
  are discussed in [I-D.ietf-lisp].  Section 12 provides additional
  issues and concerns raised by this document.  In particular,
  Section 12.1 provides details about the ETRs' synchronization issue
  in the context of Map-Versioning.

- - - -

Updated Discuss for version -15

Updated the first point of my Discuss after conversation with Jari to
add details of what I would like to see.

The LISP Charter says (of the WG)...
Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic.

I do not find such disclaimers in this document.

Section 5 is a good collection of issues for future analysis, but is
not the same thing.

The sort of think I am looking for is in two places. Please note that
you should edit and fill in the blanks as appropriate; this is just a
stake in the ground.

Abstract:
  There are several concerns for the implications for Internet traffic
  associated with this experiement, and these are described within
  the document.

Introduction
  Section 5 of this document lists some open issues and considerations
  that are not completely understood. These issues should be taken into
  consideration when experimenting with the technoclogy described in
  this document. In particular, there are limitations of this specification
  with respect to Internet traffic as follows .

NOTE: When my Discuss on draft-ietf-lisp has been addressed, it may be
possible to address this issue with a pointer to the relevant text in
draft-ietf-lisp as discussed in email.

[Ballot comment]
After much discussion I didn't manage to convince the authors to
add good-looking text on this, so eventually, I folded on this.

#2 This discuss point is "moved" from -alt: after discussion and
clarification the fix is apparently better here. There is a minor interop
issue even with the manual keying implied here - some text is needed
to say that implementations MUST, e.g. do whatever it is that's been
tested and interop'd (or some subset of that that's sufficient) which I
think basically amounts to specifying some inputs that MUST be usable
as secrets (or the equivalent).

This is an interoperability issue though and not just a deployment
problem - if two nodes implement different stuff and one has a key
installed already then absent this text it might not be possible to get
those two nodes to interop if the already installed key on node1 cannot
be entered into node2 somehow.

[Ballot discuss]
I have a discuss on -19 of the base document relating to the ability
to replay map register messages. See the discuss on the base
document for more detail. (Its not yet clear what fix where might
best resolve this issue.)

[Ballot discuss]
Updated Discuss for version -15

Thanks for addressing all but my "scope qualification" issue. I will
continue to discuss this with the ADs and chairs (progress is being
made).

Updated the first point of my Discuss after conversation with Jari to
add details of what I would like to see.

The LISP Charter says (of the WG)...
Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic.

I do not find such disclaimers in this document.

Section 5 is a good collection of issues for future analysis, but is
not the same thing.

The sort of think I am looking for is in two places. Please note that
you should edit and fill in the blanks as appropriate; this is just a
stake in the ground.

Abstract:
  There are several concerns for the implications for Internet traffic
  associated with this experiement, and these are described within
  the document.

Introduction
  Section 5 of this document lists some open issues and considerations
  that are not completely understood. These issues should be taken into
  consideration when experimenting with the technoclogy described in
  this document. In particular, there are limitations of this specification
  with respect to Internet traffic as follows .

NOTE: When my Discuss on draft-ietf-lisp has been addressed, it may be
possible to address this issue with a pointer to the relevant text in
draft-ietf-lisp as discussed in email.

[Ballot comment]
After much discussion I didn't manage to convince the authors to
add good-looking text on this, so eventually, I folded;-)

#2 This discuss point is "moved" from -alt: after discussion and
clarification the fix is apparently better here. There is a minor interop
issue even with the manual keying implied here - some text is needed
to say that implementations MUST, e.g. do whatever it is that's been
tested and interop'd (or some subset of that that's sufficient) which I
think basically amounts to specifying some inputs that MUST be usable
as secrets (or the equivalent).

This is an interoperability issue though and not just a deployment
problem - if two nodes implement different stuff and one has a key
installed already then absent this text it might not be possible to get
those two nodes to interop if the already installed key on node1 cannot
be entered into node2 somehow.

[Ballot discuss]
I have a discuss on -19 of the base document relating to the ability
to replay map register messages. See the discuss on the base
document for more detail. (Its not yet clear what fix where might
best resolve this issue.)

[Ballot discuss]
#1 Updated discuss after reviewing [LISP]. Other points were cleared in -13
of this one.

I have a discuss on -18 of the base document relating to the ability
to replay map register messages.

I guess we can discuss how to sensibly handle all that. For example,
would it be reasonable to say that whatever anti-replay mechanism
is provided by [LISP-SEC] SHOULD be used either in this doc
or in -17 of the base?

#2 This discuss point is "moved" from -alt: after discussion and
clarification the fix is apparently better here. There is a minor interop
issue even with the manual keying implied here - some text is needed
to say that implementations MUST, e.g. do whatever it is that's been
tested and interop'd (or some subset of that that's sufficient) which I
think basically amounts to specifying some inputs that MUST be usable
as secrets (or the equivalent).

This is an interoperability issue though and not just a deployment
problem - if two nodes implement different stuff and one has a key
installed already then absent this text it might not be possible to get
those two nodes to interop if the already installed key on node1 cannot
be entered into node2 somehow.

[Ballot discuss]
#1 Updated discuss after reviewing [LISP]. Other points were cleared in -13
of this one.

I have a discuss on -17 of the base document relating to the ability
to replay map register messages.

This document seems to say that LISP-SEC (which is a normative
reference here) provides a solution for that. (LISP-SEC is an
informative reference for the base document.)

I guess we can discuss how to sensibly handle all that. For example,
would it be reasonable to say that whatever anti-replay mechanism
is provided by [LISP-SEC] SHOULD be used either in this doc
or in -17 of the base?

#2 This discuss point is "moved" from -alt: after discussion and
clarification the fix is apparently better here. There is a minor interop
issue even with the manual keying implied here - some text is needed
to say that implementations MUST, e.g. do whatever it is that's been
tested and interop'd (or some subset of that that's sufficient) which I
think basically amounts to specifying some inputs that MUST be usable
as secrets (or the equivalent).

This is an interoperability issue though and not just a deployment
problem - if two nodes implement different stuff and one has a key
installed already then absent this text it might not be possible to get
those two nodes to interop if the already installed key on node1 cannot
be entered into node2 somehow.

[Ballot discuss]
Section 4.2:
Section 4.4

In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?

------------------------------------------------------------------------------
Section 4.4

How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.

---------------------------------------------------------------------------------
Section 4.4

Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.

----------------------------------------------------------------------------------
Section 4.4

Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly (e.g., prefix overlap)? If so, what are those rules? What mechanisms enforce them.

[Ballot discuss]
Section 4.2:
Section 4.4

In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?

------------------------------------------------------------------------------
Section 4.4

How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.

---------------------------------------------------------------------------------
Section 4.4

Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.

----------------------------------------------------------------------------------
Section 4.4

Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly (e.g., prefix overlap)? If so, what are those rules? What mechanisms enforce them.

[Ballot discuss]
Updated discuss after reviewing [LISP]. Other points were cleared in -13
of this one.

I have a discuss on -17 of the base document relating to the ability
to replay map register messages.

This document seems to say that LISP-SEC (which is a normative
reference here) provides a solution for that. (LISP-SEC is an
informative reference for the base document.)

I guess we can discuss how to sensibly handle all that. For example,
would it be reasonable to say that whatever anti-replay mechamism
is provided by [LISP-SEC] SHOULD be used either in this doc
or in -17 of the base?

[Ballot discuss]
Updated the first point of my Discuss after conversation with Jari to add details of what I would like to see.

The LISP Charter says (of the WG)...
Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic.

I do not find such disclaimers in this document.

Section 5 is a good collection of issues for future analysis, but is
not the same thing.

The sort of think I am looking for is in two places. Please note that you should edit and fill in the blanks as appropriate; this is just a stake in the ground.

Abstract:
  There are several concerns for the implications for Internet traffic
  associated with this experiement, and these are described within
  the document.

Introduction
  Section 5 of this document lists some open issues and considerations
  that are not completely understood. These issues should be taken into
  consideration when experimenting with the technoclogy described in
  this document. In particular, there are limitations of this specification
  with respect to Internet traffic as follows .

---

Section 2

  Map Server:  a network infrastructure component which learns EID-to-
      RLOC mapping entries from an authoritative source (typically, an
      ETR, via the registration mechanism described below).

I couldn't find a description of other authoritative sources.

---

Section 4.1

  o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
      possibly from a Map Server answering on behalf of the ETR.  Note
      that the stateless nature of non-caching Map Resolver forwarding
      means that the Map-Reply may not be from the Map Resolver to which
      the Encapsulated Map-Request was sent unless the target Map
      Resolver offers caching.  See (Section 4.4) for more details on
      Map Resolver message processing.

This is the first mention of the "stateless nature" of MR forwarding.
The forward reference to 4.4 is helpful, but that indicates that one of
the modes of operation is stateful frowarding (using the nonce).

This is also the first indication (or rather the forward reference to
4.4 provides the first indication) that an MR might forward the request
to another MR rather than direct to the ETR. I think that all the text
up to this point has given the impression that the longest query flow is
ITR-MR-ETR. It would be really helpful to bring out this fact earlier in
the document.

I think this might be aided by some clear description of the
architecture in use and the roles of the components. A figure might even
help.

---

Section 4.2

  Map-Register messages are sent periodically from an ETR to a Map
  Server with a suggested interval between messages of one minute.  A
  Map Server should time-out and remove an ETR's registration if it has
  not received a valid Map-Register message within the past three
  minutes.  When first contacting a Map Server after restart or changes
  to its EID-to-RLOC database mappings, an ETR may initially send Map-
  Register messages at an increased frequency, up to one every 20
  seconds.  This "quick registration" period is limited to five minutes
  in duration.

I understand why this is a good idea when an ETR starts, but it seems a
big risk when a MS starts. In that case, there may be a large number of
ETRs making contact and all sending Map-Reegister messages. The more
rapid transmission means that the MS's queue (which might in any case be
getting quite full) will get very full, yet many of the messages will be
unnecessary duplicates.

---

Section 4.2

  Note that a one-minute minimum registration interval during
  maintenance of an ETR-MS association does set a lower-bound on how
  quickly and how frequently a mapping database entry can be updated.
  This may have implications for what sorts of mobility can supported
  directly by the mapping system.

A peculiar paragraph given that we have just been told that the period
for sending the messages is only suggested at one minute.

  Map-Register messages are sent periodically from an ETR to a Map
  Server with a suggested interval between messages of one minute.

Surely the choice of words here implies that an ETR can send a Map-
Register whenever it considers it appropriate.

---

removed from Discuss

---

Section 4.4.1 is rather sparse.

I wonder if you should punt this "for future study" rather than open
the gates here but not address the issues. For example, when you use
any-cast MRs I assume that the ITR will receive multiple responses.
That would mean that this document should discuss the case and explain
how the ITR selects between (potentially different) non-authoratative
responses.

[Ballot discuss]
Updated the first point of my Discuss after conversation with Jari to add details of what I would like to see.

The LISP Charter says (of the WG)...
Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic.

I do not find such disclaimers in this document.

Section 5 is a good collection of issues for future analysis, but is
not the same thing.

The sort of think I am looking for is in two places. Please note that you should edit and fill in the blanks as appropriate; this is just a stake in the ground.

Abstract:
  There are several concerns for the implications for Internet traffic
  associated with this experiement, and these are described within
  the document.

Introduction
  Section 5 of this document lists some open issues and considerations
  that are not completely understood. These issues should be taken into
  consideration when experimenting with the technoclogy described in
  this document. In particular, there are limitations of this specification
  with respect to Internet traffic as follows .

---

Section 2

  Map Server:  a network infrastructure component which learns EID-to-
      RLOC mapping entries from an authoritative source (typically, an
      ETR, via the registration mechanism described below).

I couldn't find a description of other authoritative sources.

---

Section 4.1

  o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
      possibly from a Map Server answering on behalf of the ETR.  Note
      that the stateless nature of non-caching Map Resolver forwarding
      means that the Map-Reply may not be from the Map Resolver to which
      the Encapsulated Map-Request was sent unless the target Map
      Resolver offers caching.  See (Section 4.4) for more details on
      Map Resolver message processing.

This is the first mention of the "stateless nature" of MR forwarding.
The forward reference to 4.4 is helpful, but that indicates that one of
the modes of operation is stateful frowarding (using the nonce).

This is also the first indication (or rather the forward reference to
4.4 provides the first indication) that an MR might forward the request
to another MR rather than direct to the ETR. I think that all the text
up to this point has given the impression that the longest query flow is
ITR-MR-ETR. It would be really helpful to bring out this fact earlier in
the document.

I think this might be aided by some clear description of the
architecture in use and the roles of the components. A figure might even
help.

---

Section 4.2

  Map-Register messages are sent periodically from an ETR to a Map
  Server with a suggested interval between messages of one minute.  A
  Map Server should time-out and remove an ETR's registration if it has
  not received a valid Map-Register message within the past three
  minutes.  When first contacting a Map Server after restart or changes
  to its EID-to-RLOC database mappings, an ETR may initially send Map-
  Register messages at an increased frequency, up to one every 20
  seconds.  This "quick registration" period is limited to five minutes
  in duration.

I understand why this is a good idea when an ETR starts, but it seems a
big risk when a MS starts. In that case, there may be a large number of
ETRs making contact and all sending Map-Reegister messages. The more
rapid transmission means that the MS's queue (which might in any case be
getting quite full) will get very full, yet many of the messages will be
unnecessary duplicates.

---

Section 4.2

  Note that a one-minute minimum registration interval during
  maintenance of an ETR-MS association does set a lower-bound on how
  quickly and how frequently a mapping database entry can be updated.
  This may have implications for what sorts of mobility can supported
  directly by the mapping system.

A peculiar paragraph given that we have just been told that the period
for sending the messages is only suggested at one minute.

  Map-Register messages are sent periodically from an ETR to a Map
  Server with a suggested interval between messages of one minute.

Surely the choice of words here implies that an ETR can send a Map-
Register whenever it considers it appropriate.

---

Section 4.3

  If none are found, then the Map-Server returns
  a negative Map-Reply with action code "forward-native" and a 1-minute
  TTL.

Does this mean that the convergence time experienced by a device in a
site is 1-minute because the ITR will cache a failed resolution for this
amount of time. Is this a design decision of the pull nature of the ITR
in a LISP system? I couldn't find any discussion of this on a quick scan
of the base spec.

I do note that you list convergence as an open issue in Section 5 (which
is good).

---

Section 4.4.1 is rather sparse.

I wonder if you should punt this "for future study" rather than open
the gates here but not address the issues. For example, when you use
any-cast MRs I assume that the ITR will receive multiple responses.
That would mean that this document should discuss the case and explain
how the ITR selects between (potentially different) non-authoratative
responses.

[Ballot comment]
I find it very regrettable that this document was brough forward for
IESG review before the architecture and protocol on which it depends.

The very first word of the bdy of the document is a normative reference
to the base specification which is currently in AD Review with a new
revision required and a good dolop of questions from the AD for the
authors to resolve.

This means that any review of this document is necessarily moot. I am
very sorry, but I may have to come back and extend my Discuss after
we have reviewed the base spec.

I recognise that this issue is not actionable by the authors, and simply
supply it as a comment for the record. However, I strongly encourage the
authors to keep a tight track of this document since it contains
statements of protocol behavior that are lifted from the base LISP spec
and which may be subject to change. Actually, I am not clear why it is
helpful to restate protocol details (such as use of port numbers) in
this document.

---

Please expand acronyms in the Introduction on first use.

---

For clarity, it is not helpful that a LISP Map Server contains two
components called Map Resolver and Map Server. This means that the term
"Map Server" can be confusing. For example, in Section 1

  There are two types of operation for a LISP Map Server: as a Map
  Resolver, which accepts Map-Requests from an ITR and "resolves" the
  EID-to-RLOC mapping using the distributed mapping database, and as a
  Map Server, which learns authoritative EID-to-RLOC mappings from an
  ETR and publish them in the database.  A single device may implement
  one or both types of operation.

...yet in Section 4.3...

  In response to a Map-Request (received over the ALT if LISP+ALT is in
  use), the Map Server first checks to see if the destination EID
  matches a configured EID-prefix.  If there is no match, the Map
  Server returns a negative Map-Reply with action code "forward-native"
  and a 15-minute TTL.  This may occur if a Map Request is received for
  a configured aggreate EID-prefix for which no more-specific EID-
  prefix exists; it indicates the presence of a non-LISP "hole" in the
  agregate EID-prefix.

The latter implies that the "Map Server" operation processes a Map-
Request message, where the former implies that this is processed by the
"Map Resolver" operation.

---

Section 4.2

  a Map Server is typically also be configured

d/be/

---

I didn't feel that the use of LISP+ALT as an example in the text
actually helped the document. In fact, in order to get a clear view of
what the MS does, I found it helpful to skip those paragraphs.
Additionally, it felt to me that the inclusion of discussion of this
one DB scheme was prejudicing the working group's discussion of DBs.

---

Section 4.3

s/Map-Server/Map Server/

---

I really like section 5 and thank you for your frankness. The LISP
experiment might be enhanced by the addition of more details to this
section to help guide the experimenters and more quickly gather the
necessary information.

---

I confess that I found the repeated use of the same letters for flags
in different messages and different components of messages very tricky
to process. I appreciate that this would become easier with deeper
experience with the protocol, and I also understand that *this* document
can only use the assignments from the base spec. It might be wise to go
through this document making sure that all things like "S bit" are given
full context such as "the S bit of the foo message".

I *think* the same issue arrises with "nonce".

[Ballot discuss]
The LISP Charter says (of the WG)...
Its
specifications are Experimental and labeled with accurate disclaimers
about their limitations and not fully understood implications for
Internet traffic.

I do not find such disclaimers in this document.
Section 5 is a good collection of issues for future analysis, but is
not the same thing.

---

Section 2

  Map Server:  a network infrastructure component which learns EID-to-
      RLOC mapping entries from an authoritative source (typically, an
      ETR, via the registration mechanism described below).

I couldn't find a description of other authoritative sources.

---

Section 4.1

  o  A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or
      possibly from a Map Server answering on behalf of the ETR.  Note
      that the stateless nature of non-caching Map Resolver forwarding
      means that the Map-Reply may not be from the Map Resolver to which
      the Encapsulated Map-Request was sent unless the target Map
      Resolver offers caching.  See (Section 4.4) for more details on
      Map Resolver message processing.

This is the first mention of the "stateless nature" of MR forwarding.
The forward reference to 4.4 is helpful, but that indicates that one of
the modes of operation is stateful frowarding (using the nonce).

This is also the first indication (or rather the forward reference to
4.4 provides the first indication) that an MR might forward the request
to another MR rather than direct to the ETR. I think that all the text
up to this point has given the impression that the longest query flow is
ITR-MR-ETR. It would be really helpful to bring out this fact earlier in
the document.

I think this might be aided by some clear description of the
architecture in use and the roles of the components. A figure might even
help.

---

Section 4.2

  Map-Register messages are sent periodically from an ETR to a Map
  Server with a suggested interval between messages of one minute.  A
  Map Server should time-out and remove an ETR's registration if it has
  not received a valid Map-Register message within the past three
  minutes.  When first contacting a Map Server after restart or changes
  to its EID-to-RLOC database mappings, an ETR may initially send Map-
  Register messages at an increased frequency, up to one every 20
  seconds.  This "quick registration" period is limited to five minutes
  in duration.

I understand why this is a good idea when an ETR starts, but it seems a
big risk when a MS starts. In that case, there may be a large number of
ETRs making contact and all sending Map-Reegister messages. The more
rapid transmission means that the MS's queue (which might in any case be
getting quite full) will get very full, yet many of the messages will be
unnecessary duplicates.

---

Section 4.2

  Note that a one-minute minimum registration interval during
  maintenance of an ETR-MS association does set a lower-bound on how
  quickly and how frequently a mapping database entry can be updated.
  This may have implications for what sorts of mobility can supported
  directly by the mapping system.

A peculiar paragraph given that we have just been told that the period
for sending the messages is only suggested at one minute.

  Map-Register messages are sent periodically from an ETR to a Map
  Server with a suggested interval between messages of one minute.

Surely the choice of words here implies that an ETR can send a Map-
Register whenever it considers it appropriate.

---

Section 4.3

  If none are found, then the Map-Server returns
  a negative Map-Reply with action code "forward-native" and a 1-minute
  TTL.

Does this mean that the convergence time experienced by a device in a
site is 1-minute because the ITR will cache a failed resolution for this
amount of time. Is this a design decision of the pull nature of the ITR
in a LISP system? I couldn't find any discussion of this on a quick scan
of the base spec.

I do note that you list convergence as an open issue in Section 5 (which
is good).

---

Section 4.4.1 is rather sparse.

I wonder if you should punt this "for future study" rather than open
the gates here but not address the issues. For example, when you use
any-cast MRs I assume that the ITR will receive multiple responses.
That would mean that this document should discuss the case and explain
how the ITR selects between (potentially different) non-authoratative
responses.

[Ballot discuss]
Updated..again..

#1) (no action required) I get know why the doc primarily talks about LISP+ALT.

#2) s4.2 contains the following:

  A Map-Register message includes
  authentication data, so prior to sending a Map-Register message, the
  ETR and Map Server must be configured with a secret shared-key.

I figured I'd find something in lisp-sec about this, but that draft points back to this one.  I'll note that s7 contains the following:

  During experimental and prototype deployment, authentication key
  changes will be manual.

But, I don't think it's just changes that get done manually.  It's also initial configuration.  That ought to be called out either in s4.2 or 7.

[Ballot discuss]
Updated..

#1) s1 introduces the idea of multiple databases (NERD, CONS, LISP+ALT), but the rest of the document only discusses LISP+ALT.  Does the rest of the document need to be made generic or have the authors slanted the deck for LISP+ALT?  Is this because CONS is expired, NERD looks like an ISE submission, and LISP+ALT is a WG draft?

#2) s4.2 contains the following:

  A Map-Register message includes
  authentication data, so prior to sending a Map-Register message, the
  ETR and Map Server must be configured with a secret shared-key.

I figured I'd find something in lisp-sec about this, but that draft points back to this one.  I'll note that s7 contains the following:

  During experimental and prototype deployment, authentication key
  changes will be manual.

But, I don't think it's just changes that get done manually.  It's also initial configuration.  That ought to be called out either in s4.2 or 7.

[Ballot comment]
#1) I support Stephen's discusses.

#2) s1: I support Ron's discuss about the term "Map Server" is overloaded.

#3) Half-tongue-in-cheek: what no ping message to see if the peer is alive? ;)

#4) s2: Maybe add to the last paragraph: "the port number assignments".  I figured oh this protocol does have some assignments - they do they're just not in this draft ;)

[Ballot comment]
#1) I support Stephen's discusses.

#2) s1: I support Ron's discuss about the term "Map Server" is overloaded.

#3) Half-tongue-in-cheek what no ping message to see if the peer is alive? ;)

#4) s2: Maybe add to the last paragraph: "the port number assignments".  I figured oh this protocol does have some assignments - they do they're just not in this draft ;)

[Ballot discuss]
s1 introduces the idea of multiple databases (NERD, CONS, LISP+ALT), but the rest of the document only discusses LISP+ALT.  Does the rest of the document need to be made generic or have the authors slanted the deck for LISP+ALT?  Is this because CONS is expired, NERD looks like an ISE submission, and LISP+ALT is a WG draft?

[Ballot comment]
- Section 1, 2nd para says that a "Map Server" can be a "Map Resolver"
or a "Map Server" - huh? Terminology a bit messed up there really it
seems. I'd suggest inventing a new term for one of the uses of "Map
Server."

- Definition of Map Resolver says "quickly" and "immediately" which are
being used as marketing terms it seems. Better not to do that.

- Map Request defn: Be good to point out somewhere (IANA considerations
I guess) that port 4342 is already registered.

- Map register defn: is "its" associated EID-prefixes correct? That
implies there's no way for some other node to register EIDs on
behalf of a bunch of ETRs for example.

- typo: s/outdate, cached/outdated, cached/

- Text in 4.1 is inconsistent about whether an ITR has one or can
have more than one map resolver configured. I assume that "one or
more" is the right rule, if not, you should probably say.

- 4.1 - I've no clue why a negative map reply has to have a
15 minute ttl - why is that? (Same for other fixed TTL values.)

- On the topic of an ETR registering bogus aggregates. It might be that
a system like LISP could often detect that and react to it by dropping
that ETR? Say if there were an error alerting system built into the LISP
mapping store - when an ITR sees above-threshold errors for a given ETR
it tells its resolver, when the resolver sees above threshold errors it
passes that back etc. Not suggesting that you add that now, just a
thought.


- typo: s/outdate, cached/outdated, cached/

[Ballot discuss]
(added a few more points following further reading)

- Section 2, definition of Map Server (and elsewhere) refers to *the*
distributed mapping database. But you've previously said there are
multiple schemes LISP+ALT etc so how can you talk about *the*
distributed database? I think database needs to be used in the plural
with possible consequences elsewhere (e.g. security guarantees might be
DB dependant, implying that DB naming needs to be present in other
messages). If, however, it is one DB, then you'll need to explain
how LISP+ALT and others are really different schemes but yet use the
same DB with the same guarantees.

- In this case, the packet definitions are in the base document, so its
not really possible to review sections 4 & 5 of this properly without
first doing base.  (When I got to the last sentence of section 3, my
thought was: "Ah, FFS...";-)

- 4.2: provision a shared secret - it seems odd to preclude signatures
for authenticating map register messages at this level. Why do that?
If you don't need to then I'd suggest s/secret shared-key/shared secret
or other relevant authentication information/

- I may need to come back about the security considerations of this
document after I've reviewed [LISP] and [LISP-SEC].

[Ballot discuss]
(Discuss has been updated yet again, based on information gleaned from the versioning draft)

General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review,  the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------
Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Are all RLOCs required? Must they include the same attributes and version numbers.

This document is silent in that regard, however, the versioning document says:

"Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping, including the same Map-Version number.  In principle this is orthogonal to whether or not map-versioning is used.  The synchronization problem is out of the scope of this document."

This leads us to the following questions:

- How are all ETRs servicing an EID kept in sync?
- What are the consequence of becoming out of sync?

Section 8.1 of the Versioning document says:

"So far, LISP does not provide any specific synchronization mechanism,  but assumes that synchronization is provided by configuring the different xTRs consistently."

Section 8.1 of the Versioning document also demonstrates that loss of synchronization can cause network failure, whether or not version checking is enabled.

I doubt if a manual ETR synchronization process will be sufficient. What happens during the period between the configuration of one ETR and another? What happens in case of operator error? What happens when one ETR goes offline, another is reconfigured, and the first comes back on line?

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

------------------------------------------------------------------------

Section 4.4

In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?

------------------------------------------------------------------------------
Section 4.4

How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.

---------------------------------------------------------------------------------
Section 4.4

Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.

----------------------------------------------------------------------------------
Section 4.4

Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly? If so, what are those rules? What mechanisms enforce them.

[Ballot discuss]
(Discuss has been updated yet again, based on information gleaned from the versioning draft)

General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review,  the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------
Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Are all RLOCs required? Must they include the same attributes and version numbers.

This document is silent in that regard, however, the versioning document says:

"Indeed, ETRs belonging to the same LISP site must return for a specific EID-prefix the same mapping, including the same Map-Version number.  In principle this is orthogonal to whether or not map-versioning is used.  The synchronization problem is out of the scope of this document."

This leads us to the following questions:

- How are all ETRs servicing an EID kept in sync?
- What are the consequence of becoming out of sync?

At very least, the consequences of becoming out-of-sync should be well understood. If those consequences are severe, a manual process for keeping ETR information in sync will not suffice.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

------------------------------------------------------------------------

Section 4.4

In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?

------------------------------------------------------------------------------
Section 4.4

How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.

---------------------------------------------------------------------------------
Section 4.4

Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.

----------------------------------------------------------------------------------
Section 4.4

Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly? If so, what are those rules? What mechanisms enforce them.

[Ballot discuss]
(Discuss has been updated)

General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review,  the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------
Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

------------------------------------------------------------------------
Section 4.2:

What happens when two ETRs register the same EID, but with slightly different attributes. Does the registration bounce back an forth from one configuration to another as each ETR refreshes its registration?

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.

------------------------------------------------------------------------

Section 4.4

In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?

------------------------------------------------------------------------------
Section 4.4

How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.

---------------------------------------------------------------------------------
Section 4.4

Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.

----------------------------------------------------------------------------------
Section 4.4

Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly? If so, what are those rules? What mechanisms enforce them.

[Ballot discuss]
(Discuss has been updated)

General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review,  the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------
Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

------------------------------------------------------------------------
Section 4.2:

What happens when two ETRs register the same EID, but with slightly different attributes. Does the registration bounce back an forth from one configuration to another as each ETR refreshes its registration? Does the answer to this question change if the ETRs and Map Servers implement Map Versioning?

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.

------------------------------------------------------------------------

Section 4.4

In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?

------------------------------------------------------------------------------
Section 4.4

How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.

---------------------------------------------------------------------------------
Section 4.4

Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.

----------------------------------------------------------------------------------
Section 4.4

Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly? If so, what are those rules? What mechanisms enforce them.

[Ballot comment]
- Section 1, 2nd para says that a "Map Server" can be a "Map Resolver"
or a "Map Server" - huh? Terminology a bit messed up there really it
seems. I'd suggest inventing a new term for one of the uses of "Map
Server."

- Definition of Map Resolver says "quickly" and "immediately" which are
being used as marketing terms it seems. Better not to do that.

- Map Request defn: Be good to point out somewhere (IANA considerations
I guess) that port 4342 is already registered.

- Map register defn: is "its" associated EID-prefixes correct? That
implies there's no way for some other node to register EIDs on
behalf of a bunch of ETRs for example.

- typo: s/outdate, cached/outdated, cached/

- Text in 4.1 is inconsistent about whether an ITR has one or can
have more than one map resolver configured. I assume that "one or
more" is the right rule, if not, you should probably say.

- 4.1 - I've no clue why a negative map reply has to have a
15 minute ttl - why is that? (Same for other fixed TTL values.)

- On the topic of an ETR registering bogus aggregates. It might be that
a system like LISP could often detect that and react to it by dropping
that ETR? Say if there were an error alerting system built into the LISP
mapping store - when an ITR sees above-threshold errors for a given ETR
it tells its resolver, when the resolver sees above threshold errors it
passes that back etc. Not suggesting that you add that now, just a
thought.


- typo: s/outdate, cached/outdated, cached/

[Ballot discuss]
(added a few more points following further reading)

- Section 2, definition of Map Server (and elsewhere) refers to *the*
distributed mapping database. But you've previously said there are
multiple schemes LISP+ALT etc so how can you talk about *the*
distributed database? I think database needs to be used in the plural
with possible consequences elsewhere (e.g. security guarantees might be
DB dependant, implying that DB naming needs to be present in other
messages). If, however, it is one DB, then you'll need to explain
how LISP+ALT and others are really different schemes but yet use the
same DB with the same guarantees.

- In this case, the packet definitions are in the base document, so its
not really possible to review sections 4 & 5 of this properly without
first doing base.  (When I got to the last sentence of section 3, my
thought was: "Ah, FFS...";-)

- 4.2: provision a shared secret - it seems odd to preclude signatures
for authenticating map register messages at this level. Why do that?
If you don't need to then I'd suggest s/secret shared-key/shared secret
or other relevant authentication information/

- What prevents an ETR registering a bogus aggregate?  Don't you need to
say that the map server has to at least do some out of band sanity
checks or something?

- I may need to come back about the security considerations of this
document after I've reviewed [LISP] and [LISP-SEC].

[Ballot discuss]
(Discuss has been updated)

General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review,  the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.

------------------------------------------------------------------------

Section 4.4

In bullet number 2, you describe how the caching map generates a new nonce, stores that nonce and uses it in a locally generated Map-Request. How long should the resolver wait for a map-response before flushing state regarding the locally generated map-request?

------------------------------------------------------------------------------
Section 4.4

How does the caching resolver protect itself from a trivial DoS attack, in which it receives a sustained stream of Map-Request. The map requests appear to come from multiple, legitimate ITRs, but the ITR source RLOCs are spoofed. Also, the requested EID mappings requested are well-randomized.

---------------------------------------------------------------------------------
Section 4.4

Is it wise to run an open, caching resolver? Or should requests to a caching resolver be authenticated.

----------------------------------------------------------------------------------
Section 4.4

Are there any database consistency rules regarding the resolver cache? For example, is there any case where flushing one cache entry before another would cause the resolver to behave badly? If so, what are those rules? What mechanisms enforce them.

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review,  the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.

----------------------------------------------------------------------------
Section 4.4

The map resolver cache appears vulnerable to trivial DoS attacks. Will the Resolver work just as well when the cache is overrun? If so, why bother to implement it?


------------------------------------------------------------------------

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review, and given that trust boundaries and security requirements are not well understood, the abstract and introduction should warn users against deploying LISP MS in mission critical, production environments.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.

----------------------------------------------------------------------------
Section 4.4

The map resolver cache appears vulnerable to trivial DoS attacks. Will the Resolver work just as well when the cache is overrun? If so, why bother to implement it?


------------------------------------------------------------------------

[Ballot comment]
- Section 1, 2nd para says that a "Map Server" can be a "Map Resolver"
or a "Map Server" - huh? Terminology a bit messed up there really it
seems. I'd suggest inventing a new term for one of the uses of "Map
Server."

- Definition of Map Resolver says "quickly" and "immediately" which are
being used as marketing terms it seems. Better not to do that.

- Map Request defn: Be good to point out somewhere (IANA considerations
I guess) that port 4342 is already registered.

- Map register defn: is "its" associated EID-prefixes correct? That
implies there's no way for some other node to register EIDs on
behalf of a bunch of ETRs for example.

- typo: s/outdate, cached/outdated, cached/

[Ballot discuss]
- Section 2, definition of Map Server (and elsewhere) refers to *the*
distributed mapping database. But you've previously said there are
multiple schemes LISP+ALT etc so how can you talk about *the*
distributed database? I think database needs to be used in the plural
with possible consequences elsewhere (e.g. security guarantees might be
DB dependant, implying that DB naming needs to be present in other
messages). If, however, it is one DB, then you'll need to explain
how LISP+ALT and others are really different schemes but yet use the
same DB with the same guarantees.

- In this case, the packet definitions are in the base document, so its
not really possible to review sections 4 & 5 of this properly without
first doing base.  (When I got to the last sentence of section 3, my
thought was: "Ah, FFS...";-)

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

General:

Given the considerations raised in Section 5 and in this review, the abstract and introduction should warn users against deploying LISP in mission critical, production networks.

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.

----------------------------------------------------------------------------
Section 4.4

The map resolver cache appears vulnerable to trivial DoS attacks. Will the Resolver work just as well when the cache is overrun? If so, why bother to implement it?


------------------------------------------------------------------------

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.

----------------------------------------------------------------------------
Section 4.4

The map resolver cache appears vulnerable to trivial DoS attacks. Will the Resolver work just as well when the cache is overrun? If so, why bother to implement it?


more to come

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document, LISP ALT  and LISP SEC have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.


more to come

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document and LISP ALT have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

-------------------------------------------------------------------------
Section 4.3

You say:

"If none of the ETRs have requested proxy reply service, then the Map  Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs."

Are all of the ETRs guaranteed to give the same response (i.e., the same set of RLOCs).  If so, it doesn't matter which ETR we chose. If not, we have to figure out which ETR should receive the request.


more to come

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document and LISP ALT have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------

Section 4.3

What does the Map Server do if it receives a Map Request for a prefix that is outside of its aggregate (i.e., something that it never advertised into ALT using BGP). Shouldn't the Negative Map Reply indicate that something appears to be amiss?

more to come

[Ballot comment]
Section 4.2

You say:

"In addition to the set of EID-prefixes defined for each ETR that may register, a Map Server is typically also be configured with one or more aggregate prefixes that define the part of the EID numbering space assigned to it."

Grammar.
----------------------------------------------------------------------------


Section 4.3:

You say:

"If any of the registered ETRs for the EID-prefix have requested proxy reply service, then the Map Server answered the request instead of forwarding it."

Grammar

[Ballot discuss]
General:

This document cannot be reviewed meaningfully before the LISP base document and LISP ALT have been reviewed.

General:

Where are the trust boundaries in this system? Can all ALT nodes trust one another because they reside within the same security domain? Can all Map Servers trust one another because they reside within the same security domain? This question is important because it determines where security mechanisms are required.

How are the trust boundaries maintained? Do all devices that reside within a trust boundary need to be managed by the same party?

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------

Section 4.2:

In paragraph 6 you say:

"When an ETR requests proxy reply service, it should include all RLOCs for all ETRs for the EID-prefix being registered, along with the "R" bit setting for each RLOC."

What should the Map-Register message include when it does not request the proxy reply service? Just its own RLOC? You never say.

-------------------------------------------------------------------------
more to come

[Ballot discuss]
General:

Who operates the Map Server? Where are its trust boundaries?

Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------


-------------------------------------------------------------------------
more to come

[Ballot discuss]
Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 you introduce the Resolver function for the first time. This causes the reader to go back and reinterpret what was read in the two previous paragraphs, understanding that these paragraphs address the Map Server function, not the Map Server device.

Please fix this. Also, in Paragraph 1, be specific about from whence the Map Request come.

------------------------------------------------------------------------------


-------------------------------------------------------------------------
more to come

[Ballot discuss]
Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

-----------------------------------------------------------------------------
Section 3:

The opening words of Section 3, Paragraph 1 imply that you are speaking generically about the Map Server Device (both the Map Server and Resolver functions). However, the opening words of Section 3, Paragraph 3 make clear that in the first two paragraphs, you were speaking more specifically about the Map Server device in the Map Server function. This causes the reader to reinterpret what was read in the first two paragraphs. (for example, it causes the reader to go back and rethink from whence the Map Request came in Paragraph 1.

Please rework this entire section.

-------------------------------------------------------------------------
more to come

[Ballot discuss]
Section 1:

In the second paragraph of Section 1, you say:

"There are two types of operation for a LISP Map Server: as a Map Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map Server, which learns authoritative EID-to-RLOC mappings from an ETR and publish them in the database.  A single device may implement  one or both types of operation.

In this paragraph, the term "Map Server" is overloaded. A Map Server can be a device or one of the two functions that the device can serve. Please fix this. It makes the rest of the document unnecessarily difficult to read.

--------------------------------------------------------------------------------------------------------------

more to come

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (LISP Map Server) to Experimental RFC


The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP Map Server'
  as an Experimental 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 2011-09-28. 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 draft describes the LISP Map Server (LISP-MS), a computing
  system which provides a simplified LISP protocol interface as a
  "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC)
  mapping database and associated virtual network of LISP protocol
  elements.

  The purpose of the Map Server is to reduce implementation and
  operational complexity of LISP Ingress Tunnel Routers (ITRs) and
  Egress Tunnel Routers (ETRs), the devices that implement the "edge"
  of the LISP infrastructure and which connect directly to LISP-capable
  Internet end sites.




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

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


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

I have reviewed this specification. I think it is ready to move forward, and I have sent it to IETF Last Call. I did see a couple of minor editorial issues, however (see below). You may fix those either by issuing a new draft or wait until further issues are brought up in directorate or other reviews.

>    In addition to the set of EID-prefixes defined for each ETR that may
>    register, a Map Server is typically also be configured with one or
>    more aggregate prefixes that define the part of the EID numbering
>    space assigned to it.

s/also be/also/

>    An ETR may also request, by setting the "proxy-map-reply" flag
>    (P-bit) in the Map-Regsiter message

Map-Register

Jari

(1.a) Joel Halpern is the Shepherd and has reviewed this version
and believes it is ready to be forwarded to the IESG.

(1.b) The document has had adequate review. The shepherd has no concerns
regarding the reviews which have been performed.

(1.c) The document shepherd does not have concerns that the document
requires a broader review.

(1.d) The document shepherd has no specific concerns, No IPR disclosures
have been raised.

(1.e) The WG consensus reflects active agreement among about about 10
participants, with the bulk of the WG being silent, and a few vocal
objectors.

(1.f) No threats of appeal or discontent on this document have manifested.

(1.g) IDNITs reported no issues.


(1.h) References have been split. No downward normative references exist.
Several normative references exist that are WIP, these will be sent
to the IESG as a cluster to be processed in parallel.

(1.i) The document makes no request of the IANA

(1.j) Formal language has been verified.

(1.k)

Technical Summary

This draft describes the LISP Map Server (LISP-MS), a computing
system which provides a simplified LISP protocol interface as a
"front end" to the Endpoint-ID (EID) to Routing Locator (RLOC)
mapping database and associated virtual network of LISP protocol
elements.

The purpose of the Map Server is to reduce implementation and
operational complexity of LISP Ingress Tunnel Routers (ITRs) and
Egress Tunnel Routers (ETRs), the devices that implement the "edge"
of the LISP infrastructure and which connect directly to LISP-capable
Internet end sites.


Working Group Summary

The Last call for this document was extended to try to capture
all concerns. There were concerns raised on caching and security
effects. These have been included in the document as identified
points in the relevant sections given that the document is
Experimental. The SECURITY area required consideration of AKM.

Document Quality

There are 4 confirmed different implementations of LISP
including map-server code, and the document has been reviewed
at length with all the other LISP drafts reaching last call.