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

From: Brian Haberman <[email-masked]>
Date: Wed, 14 Jan 2015 11:26:15 -0500

All,
     I have completed by AD Evaluation of draft-ietf-lisp-introduction
as a part of the IETF publication process.  I have some
comments/questions that should be resolved prior to starting an IETF
Last Call.  Please let me know if you have any questions on these...

1. Section 1

* I am going to try and short-circuit the inevitable question that will
arise about the reference [Chiappa].  Since it is a web page, the RFC
Editor will be concerned by its long-term stability.  Is that the best
reference for that text?  Anything similar that has been published in a
conference/journal/RFC/etc.?

* The text uses the terms underlay and overlay without any context (in
the summary bullets).  This is easily fixed by augmenting the text in
the 2nd paragraph to identify which networks form the underlay and the
overlay.

2. Section 3 (and a few times in 3.5) : s/inetrworking/internetworking/

3. Section 3.2

* Is it correct to say that EIDs are only routable at the edge?  This
seems to contradict the text in section 3.5 that says EIDs may be
injected in the global routing system.

* I find the PI and PA analogies misleading.  EIDs are global, but they
may change their point of attachment.  If that occurs, you are not
guaranteed that your EID space does not change.

* In the example, bullet four mistakenly says that the destination
address of the outer header is set to RLOC_B2 (it should be RLOC_b1).

4. Section 3.3.1 introduces the term RTR (Reencapsulating Tunnel
Routers) with no real description of how it functions or relates to ITRs
and ETRs.

5. Section 3.4.3 makes reference to the LISP WG.  Given that this
document will probably outlive the WG, I would suggest re-wording to
remove a direct reference to the WG.

6. Section 3.4 has no discussion of EIDs and NATs.  Given the global
nature of the mapping system, it would seem that NATs don't play well
with LISP.  There should be some discussion of that.

7. Section 4.1

* s/requires of a /requires a/

* The discussion of SMR should contain a reference to 6830 or a brief
discussion of how the SMR is used.

8. Section 5

* I would suggest having a reference to both the MIP and the NEMO specs
when discussing mobility.  LISP has the potential to operate in a manner
conducive with NEMO if the xTR acts as the NEMO Mobile Router.

* Should there be some discussion of the mapping system's TTL mechanism
impact on mobility support?

9. Section 9 talks about propagating multicast state as (S-EID, G).
Does that mean that multicast in LISP is really only allowed to be SSM?

10. I am surprised that there are 2 Security Consideration sections (7 &
9).  I am even more surprised that one says "Nothing new here" and the
other actually discusses potential issues with the LISP approach.

Regards,
Brian

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 14 Jan 2015 10:10:51 -0800

Here are some brief responses to your comments Brian. Thanks for doing the throuogh review.

> On Jan 14, 2015, at 8:26 AM, Brian Haberman <[email-masked]> wrote:
> 
> All,

I will yield to the authors.

> the 2nd paragraph to identify which networks form the underlay and the

Those terms aren't used very much in RFC 6830 because those terms seem to become fashionable with the advent of nv03. If the authors want to continue to use those terms, I have no problem with that, but would suggest that the Definition of Terms section say that the underlay is what is referred to in RFC 6830 as "the underlying core routing system". And that an "overlay" is the encapsulation relationship between ITRs, ETRs, PxTRs, and RTRs.

> injected in the global routing system.

Well it depends on your reference point. If the overlay is the center of perspective, then the global routing system is a non-LISP site relative to the overlay. The whole point is that EIDs are routable where LISP is not available. And that is true inside of a LISP site where packets are at a point in the data-path pre-encapsulation or post-decapsulation.

> guaranteed that your EID space does not change.

It is desirable that your EIDs do not change. But the scope of EID mobility may be limited and if a legacy site wants to continue to use DHCP and address addresses out of, say an enterprise address pool, it should be able to do that while losing session survivability features. That is a decision for the organization that is supporting mobility into its own domain.

> Routers) with no real description of how it functions or relates to ITRs

Well there are references to it in RFC 6830 and there are many use-cases for them which we are not allowed to reference since the drafts are not working group documents.

> with LISP.  There should be some discussion of that.

LISP plays very well with NATs and we have many use-cases which are alive and being used. But again the draft on  NAT-traversal is not a working group document so it is hard to reference it. EIDs are translatable by NATs and so are RLOCs. It all depends where the xTR resides (on the public versus private side of the NAT).

> conducive with NEMO if the xTR acts as the NEMO Mobile Router.

Well if we do that then there are a ton of other cases where a xTR can be co-located with other functions (i.e. a simple reference is say a wifi AP). So singlingly out MIP/NEMO seems to be favoring these technologies versus others. Why would we want to do that?

Plus, it raises questions more than simplifies the understanding of LISP. This is an intro document.

> impact on mobility support?

The TTL is not used for mobility to work. It is the SMR and Map-Notify mechanisms between xTRs and the mapping system and xTRs, respectively.

> Does that mean that multicast in LISP is really only allowed to be SSM?

We are encouraging SSM but an (RP-EID, G) can be used as well. RFC 6831 describes all PIM modes.

> other actually discusses potential issues with the LISP approach.

Thanks again,
Dino

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

---

From: Albert Cabellos <[email-masked]>
Date: Fri, 16 Jan 2015 17:14:07 +0100

Hi

Thank you very much for the review, please see inline my replies:

> On Jan 14, 2015, at 7:10 PM, Dino Farinacci <[email-masked]> wrote:
> 

Unfortunately I´ve been unable to find a more “stable” publication. However the exact same document is cited in RFC4423 with the following “disclaimer”:

"(…) the unpublished Internet Draft "Endpoints and Endpoint Names" [10] by Noel Chiappa (…)”

Please let me know if adding a similar sentence is enough.

> Those terms aren't used very much in RFC 6830 because those terms seem to become fashionable with the advent of nv03. If the authors want to continue to use those terms, I have no problem with that…

I think that the second paragraph already introduces many new and important concepts, what about updating the first two bullet points?

   o  RLOCs have meaning only in the underlay network, **that is the underlying core routing system.**

   o  EIDs have meaning only in the overlay network unless they are leaked into the underlay network. **The overlay is the encapsulation relationship between LISP-capable routers.**

>> 2. Section 3 (and a few times in 3.5) : s/inetrworking/internetworking/

Thanks for catching this typo.

> Well it depends on your reference point. If the overlay is the center of perspective, then the global routing system is a non-LISP site relative to the overlay. The whole point is that EIDs are rou…

What about changing the last sentence to:

Because of this, EIDs are usually routable at the edge (within LISP sites) or in the non-LISP Internet.

> It is desirable that your EIDs do not change. But the scope of EID mobility may be limited and if a legacy site wants to continue to use DHCP and address addresses out of, say an enterprise address…

I suggest removing both analogies (PI and PA), two sentences overall.

>> address of the outer header is set to RLOC_B2 (it should be RLOC_b1).

Thanks

> Well there are references to it in RFC 6830 and there are many use-cases for them which we are not allowed to reference since the drafts are not working group documents.

What about extending the last sentence of the paragraph?

Typically such functions are implemented by Reencapsulating Tunnel Routers (RTRs), **An RTR can be thought as a router that first acts as an ETR by decapsulating packets and then as an ITR by encapsulating them towards another locator.**

>> remove a direct reference to the WG.

Updated sentence:

> LISP plays very well with NATs and we have many use-cases which are alive and being used. But again the draft on  NAT-traversal is not a working group document so it is hard to reference it. EIDs a…

I will add a paragraph summarizing section 7 of RFC6832 at the end of section 3.5.

>> * s/requires of a /requires a/

Thanks

>> discussion of how the SMR is used.

Could you please elaborate further this comment?

      "Solicit-Map-Request (SMR):  SMR is an explicit mechanism to update
      mapping information.  In particular a special type of Map-Request
      can be sent on demand by ETRs to request refreshing a mapping.
      Upon reception of a SMR message, the ITR must refresh the bindings
      by sending a Map-Request to the Mapping System."

> Plus, it raises questions more than simplifies the understanding of LISP. This is an intro document.

What about adding the following sentence at the end of section 5?

The decoupled identity and location provided by LISP allows it to operate with other layer 2 and layer 3 mobility solutions.

> The TTL is not used for mobility to work. It is the SMR and Map-Notify mechanisms between xTRs and the mapping system and xTRs, respectively.

True, but mappings from LISP mobile nodes are expected to have a low TTL (1 min), what about updating the last paragraph to:

Whenever the device changes of RLOC, the xTR updates the RLOC of its
   local mapping and registers it to its Map-Server, **typically with a low TTL value (1min)**.  To avoid the need
   of a home gateway, the ITR also indicates the RLOC change to all
   remote devices that have ongoing communications with the device that
   moved. The combination of both methods ensures the scalability of
   the system as signaling is strictly limited the Map-Server and to
   hosts with which communications are ongoing.
> We are encouraging SSM but an (RP-EID, G) can be used as well. RFC 6831 describes all PIM modes.

What about rephrasing the last sentence of the Multicast section:

LISP [RFC6831] supports all PIM modes, additionally LISP can also support non-PIM mechanisms to maintain multicast state.

>> other actually discusses potential issues with the LISP approach.

My fault, Section 7 should be “LISP Security Considerations”

Section 9 describes the security considerations for the document itself.

Regards

Albert

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 16 Jan 2015 09:48:01 -0800

Albert, I agree with all your changes and suggestions. Thanks.

Dino

> On Jan 16, 2015, at 8:14 AM, Albert Cabellos <[email-masked]> wrote:
> 
> 
> Hi
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 19 Jan 2015 09:45:00 -0500

Hi Dino,

On 1/14/15 1:10 PM, Dino Farinacci wrote:
>> All, I have completed by AD Evaluation of
>> draft-ietf-lisp-introduction as a part of the IETF publication
>> process.  I have some comments/questions that should be resolved
>> prior to starting an IETF Last Call.  Please let me know if you
>> have any questions on these...
>> 
>> 1. Section 1
>> 
>> * I am going to try and short-circuit the inevitable question that
>> will arise about the reference [Chiappa].  Since it is a web page,
>> the RFC Editor will be concerned by its long-term stability.  Is
>> that the best reference for that text?  Anything similar that has
>> been published in a conference/journal/RFC/etc.?
> 
>> * The text uses the terms underlay and overlay without any context
>> (in the summary bullets).  This is easily fixed by augmenting the
>> text in the 2nd paragraph to identify which networks form the
>> underlay and the overlay.
> 
> Those terms aren't used very much in RFC 6830 because those terms
> seem to become fashionable with the advent of nv03. If the authors
> want to continue to use those terms, I have no problem with that, but
> would suggest that the Definition of Terms section say that the
> underlay is what is referred to in RFC 6830 as "the underlying core
> routing system". And that an "overlay" is the encapsulation
> relationship between ITRs, ETRs, PxTRs, and RTRs.

That is fine with me.

>> * Is it correct to say that EIDs are only routable at the edge?
>> This seems to contradict the text in section 3.5 that says EIDs may
>> be injected in the global routing system.
> 
> Well it depends on your reference point. If the overlay is the center
> of perspective, then the global routing system is a non-LISP site
> relative to the overlay. The whole point is that EIDs are routable
> where LISP is not available. And that is true inside of a LISP site
> where packets are at a point in the data-path pre-encapsulation or
> post-decapsulation.

I agree with what you say above, but the document explicitly says EIDs
are only routable at the edge and that is not the case in non-LISP parts
of the Internet.  The document just needs to be more explicit on that point.

> 
>> * I find the PI and PA analogies misleading.  EIDs are global, but
>> they may change their point of attachment.  If that occurs, you are
>> not guaranteed that your EID space does not change.
> 
> It is desirable that your EIDs do not change. But the scope of EID
> mobility may be limited and if a legacy site wants to continue to use
> DHCP and address addresses out of, say an enterprise address pool, it
> should be able to do that while losing session survivability
> features. That is a decision for the organization that is supporting
> mobility into its own domain.

Given my concern and your comment above, how does the EID/PI analogy hold?

>> Routers) with no real description of how it functions or relates to
>> ITRs and ETRs.
> 
> Well there are references to it in RFC 6830 and there are many
> use-cases for them which we are not allowed to reference since the
> drafts are not working group documents.

So, Section 3.3.1 should point the reader to 6830 when it mentions the RTR.

>> document will probably outlive the WG, I would suggest re-wording
>> to remove a direct reference to the WG.
>> 
>> 6. Section 3.4 has no discussion of EIDs and NATs.  Given the
>> global nature of the mapping system, it would seem that NATs don't
>> play well with LISP.  There should be some discussion of that.
> 
> LISP plays very well with NATs and we have many use-cases which are
> alive and being used. But again the draft on  NAT-traversal is not a
> working group document so it is hard to reference it. EIDs are
> translatable by NATs and so are RLOCs. It all depends where the xTR
> resides (on the public versus private side of the NAT).

Even though the NAT-traversal draft is not a WG draft, this document can
spend a few cycles talking about the general ability of LISP to operate
in the face of NATs.

>> * The discussion of SMR should contain a reference to 6830 or a
>> brief discussion of how the SMR is used.
>> 
>> 8. Section 5
>> 
>> * I would suggest having a reference to both the MIP and the NEMO
>> specs when discussing mobility.  LISP has the potential to operate
>> in a manner conducive with NEMO if the xTR acts as the NEMO Mobile
>> Router.
> 
> Well if we do that then there are a ton of other cases where a xTR
> can be co-located with other functions (i.e. a simple reference is
> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring these
> technologies versus others. Why would we want to do that?

MIP and NEMO are the general modes of mobility that most closely
approximate what is being discussed in Section 5.  My thought was to
give the reader a basis for how mobility in LISP operates, including the
drawbacks.

>> * Should there be some discussion of the mapping system's TTL
>> mechanism impact on mobility support?
> 
> The TTL is not used for mobility to work. It is the SMR and
> Map-Notify mechanisms between xTRs and the mapping system and xTRs,
> respectively.

Shouldn't that be mentioned somewhere in this draft?

> 
>> 9. Section 9 talks about propagating multicast state as (S-EID,
>> G). Does that mean that multicast in LISP is really only allowed to
>> be SSM?
> 

So, to avoid erroneous assumptions, perhaps the intro should mention that.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 19 Jan 2015 09:58:16 -0500

Hi Albert,

On 1/16/15 11:14 AM, Albert Cabellos wrote:
>>> * I am going to try and short-circuit the inevitable question
>>> that will arise about the reference [Chiappa].  Since it is a web
>>> page, the RFC Editor will be concerned by its long-term
>>> stability.  Is that the best reference for that text?  Anything
>>> similar that has been published in a 
> Unfortunately I´ve been unable to find a more “stable” publication.
> However the exact same document is cited in RFC4423 with the
> following “disclaimer”:
> 

I think that is fine.  Just be prepared to work with the RFC Editor on this.

> 
>> 
>>> * The text uses the terms underlay and overlay without any
>>> context (in the summary bullets).  This is easily fixed by
>>> augmenting the text in the 2nd paragraph to identify which
>>> networks form the underlay and the overlay.
>> 
>> want to continue to use those terms, I have no problem with that,
>> but would suggest that the Definition of Terms section say that the
> I think that the second paragraph already introduces many new and
> important concepts, what about updating the first two bullet points?
> 
> o  EIDs have meaning only in the overlay network unless they are
> leaked into the underlay network. **The overlay is the encapsulation
> relationship between LISP-capable routers.**

That works.

>>> This seems to contradict the text in section 3.5 that says EIDs
>>> may be injected in the global routing system.
>> 
>> Well it depends on your reference point. If the overlay is the
>> center of perspective, then the global routing system is a non-LISP
>> site relative to the overlay. The whole point is that EIDs are
>> routable where LISP is not available. And that is true inside of a
>> LISP site where packets are at a point in the data-path
>> pre-encapsulation or post-decapsulation.
>> 
> 

Yes.

> 
>>> * I find the PI and PA analogies misleading.  EIDs are global,
>>> but they may change their point of attachment.  If that occurs,
>>> you are not guaranteed that your EID space does not change.
>> 
>> mobility may be limited and if a legacy site wants to continue to
>> use DHCP and address addresses out of, say an enterprise address
>> pool, it should be able to do that while losing session
>> survivability features. That is a decision for the organization
>> that is supporting mobility into its own domain.
> 

Ok.

>> 
>>> * In the example, bullet four mistakenly says that the
>>> destination address of the outer header is set to RLOC_B2 (it
>>> should be RLOC_b1).
>>> 
> 
> Thanks
> 
>>> Routers) with no real description of how it functions or relates
>>> to ITRs and ETRs.
>> 
> Typically such functions are implemented by Reencapsulating Tunnel
> Routers (RTRs), **An RTR can be thought as a router that first acts
> as an ETR by decapsulating packets and then as an ITR by
> encapsulating them towards another locator.**
> 

The above plus a reference to 6830 would be good.

> 
>>> 5. Section 3.4.3 makes reference to the LISP WG.  Given that
>>> this document will probably outlive the WG, I would suggest
>>> re-wording to remove a direct reference to the WG.
> 
> Updated sentence:
> 
> Many of the existing mechanisms to create distributed systems have
> been explored and considered for the Mapping System architecture:

Yes.

>>> global nature of the mapping system, it would seem that NATs
>>> don't play well with LISP.  There should be some discussion of
>>> that.
>> 
>> alive and being used. But again the draft on  NAT-traversal is not
>> a working group document so it is hard to reference it. EIDs are

Sounds good.

> mapping information.  In particular a special type of Map-Request can
> be sent on demand by ETRs to request refreshing a mapping. Upon
> reception of a SMR message, the ITR must refresh the bindings by
> sending a Map-Request to the Mapping System."

There are more interesting conditions/rules for the use of SMR that are
only found in RFC 6830.  I am suggesting adding a reference to 6830 at
this point so readers know where to go to find more info on the SMR.

>>> specs when discussing mobility.  LISP has the potential to
>>> operate in a manner conducive with NEMO if the xTR acts as the
>>> NEMO Mobile Router.
>> 
>> say a wifi AP). So singlingly out MIP/NEMO seems to be favoring
>> these technologies versus others. Why would we want to do that?
>> 
> The decoupled identity and location provided by LISP allows it to
> operate with other layer 2 and layer 3 mobility solutions.

The text talks about both network (NEMO) and host (MIP) mobility.  I am
not concerned with LISP interacting with those protocols, I am thinking
of how LISP replaces those protocols.  The descriptions in Section 5
align with very well (i.e., the first paragraph describes LISP replacing
NEMO and the second paragraph describes LISP replacing MIP).  My
proposal was to simply add references in those paragraphs to the
mobility protocol that LISP is approximately.

I do like your proposed addition in order to highlight that LISP will
not interfere with other mobility solutions.

> True, but mappings from LISP mobile nodes are expected to have a low
> TTL (1 min), what about updating the last paragraph to:
> 
> local mapping and registers it to its Map-Server, **typically with a
> low TTL value (1min)**.  To avoid the need of a home gateway, the ITR
> also indicates the RLOC change to all remote devices that have
> ongoing communications with the device that moved. The combination of
> both methods ensures the scalability of the system as signaling is
> strictly limited the Map-Server and to hosts with which
> communications are ongoing.

The above would be good.

>>> G). Does that mean that multicast in LISP is really only allowed
>>> to be SSM?
>> 
> LISP [RFC6831] supports all PIM modes, additionally LISP can also
> support non-PIM mechanisms to maintain multicast state.
> 

Yes.

> 
>>> 10. I am surprised that there are 2 Security Consideration
>>> sections (7 & 9).  I am even more surprised that one says
>>> "Nothing new here" and the other actually discusses potential
>>> issues with the LISP approach.
>>> 
> 

I think maintaining two security consideration sections will be
confusing.  Either document that *this* document introduces no new
security issues or have the security considerations section summarize
the security impacts of LISP.

Regards,
Brian

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 19 Jan 2015 09:56:54 -0800

Since you responded Brian to Albert's email and have commented and agreed to most of the changes, I don't need to respond to each point below. I think we are golden. Agree?

Dino

> On Jan 19, 2015, at 6:45 AM, Brian Haberman <[email-masked]> wrote:
> 
> Hi Dino,
>

---

From: Albert Cabellos <[email-masked]>
Date: Tue, 20 Jan 2015 14:00:29 +0100

Hi

Thanks, please see inline my replies (removed text for which we all agree):

> [snip]

> this point so readers know where to go to find more info on the SMR.
Agreed, I´ll add a sentence.

Further uses of SMRs are documented in [RFC6830].

> not interfere with other mobility solutions.
What about adding two sentences at the end of each paragraph:

This functionality is similar to [RFC NEMO].
This functionality is similar to [RFC MIP] [RFC MIPv6].

 [snip]

> the security impacts of LISP.
Agreed, will do the latter (so Section 9 is now Section 7).

---

From: Brian Haberman <[email-masked]>
Date: Tue, 20 Jan 2015 08:09:46 -0500

Albert,
     That all works for me.

Regards,
Brian