Subject: [lisp] Adrian Farrel's Discuss on draft-ietf-lisp-introduction-12: (with DISCUSS and COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 03 Mar 2015 14:09:19 -0800

Adrian Farrel has entered the following ballot position for
draft-ietf-lisp-introduction-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. It is really helpful to have a clear
introduction to LISP, and I appreciate the hard work that has gone into
producing this text.

I have a small Discuss that is easily fixed. The essence is that you 
should limit this document to a description of LISP and not try to use
it to bash other solutions.

In Section 4.2

   On the contrary BGP is a
   push architecture, where the required network state is pushed by
   means of BGP UPDATE messages to BGP speakers.

You will be aware of RFC 5291 and the use of ORF to make BGP a pull-mode
protocol.

(I won't say to you that LISP is push mode because a Map-Reply pushes 
the mapping information from the map server to the client :-)

So, my advice is to describe LISP in this document and to not make
comments about other systems. It isn't a beauty contest and it isn't
wise to try to say "my system is better/different from yours".

The solution is to just remove this sentence.

Similarly in 7.1

   BGP is the standard protocol to implement inter-domain routing.  With
   BGP, routing information are propagated along the network and each
   autonomous system can implement its own routing policy that will
   influence the way routing information are propagated.  The direct
   consequence is that an autonomous system cannot precisely control the
   way the traffic will enter the network.

   As opposed to BGP, a LISP site can strictly impose via which ETRs the
   traffic must enter the the LISP site network even though the path
   followed to reach the ETR is not under the control of the LISP site.

Let's not get into the "BGP this, BGP that" debate. Just remove the 
first paragraph and the first four words of the second paragraph. That
way you avoid all contention and write a document about LISP.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a few questions and editorial nits I hope you will pick up as
additional polish. Some of the nits come from Deborah's review as AD
in-training

---

Section 1

I'm really not comfortable with your text... "Indeed and as pointed out
by the unpublished Internet Draft by Noel Chiappa [Chiappa]"

This isn't a stable reference and I don't think you need it. You could
either rely on the later reference to RFC 4984, reference RFC 6830 
itself, or take out the aside "and as... ... [Chiappa]"

---

Section 1 has

   LISP creates two separate namespaces, EIDs (End-host IDentifiers) and
   RLOCs (Routing LOCators), both are typically syntactically identical
   to the current IPv4 and IPv6 addresses.

The "typically" here opens a bit of door.

RFC 6830 explains this in the definitions of EID, but seems to be clear
that an RLOC is an IP address.

If you are opening up the RLOC to be something other than an IP address 
(a MAC address or even something else?) then how do you deal with:
- lack of ICMP
- non-uniqueness

Possibly you can say that this is "not my problem" since the problem 
would already exist in the routing system that handles the non-IP
addresses. But maybe, for an introduction to the topic this is over-
reaching towards the many potential applications rather than the basic
explanation of the architecture?

But in your own definitions in Section 2, you have 

   Endpoint IDentifier (EID):  EIDs are IPv4 or IPv6 addresses used to
      uniquely identify nodes irrespective of their topological location
      and are typically routed intra-domain.

   Routing LOcator (RLOC):  RLOCs are IPv4 or IPv6 addresses assigned
      topologically to network attachment points and typically routed
      inter-domain.

Neither of which offers any possiblitity to vary "always" into
"typically".

The again, 3.2 has...

   EIDs are typically -but
   not limited to- IPv4 or IPv6 addresses

...and...

   With LISP, the core uses RLOCs, an RLOC is typically -but not limited
   to- an IPv4 or IPv6 address

Some concistency is needed!

In 3.4.1 you finally get there...

   Typical mappings in LISP bind EIDs in the form of IP prefixes with a
   set of RLOCs, also in the form of IPs.  IPv4 and IPv6 addresses are
   encoded using the appropriate Address Family Identifier (AFI)
   [RFC3232].  However LISP can also support more general address
   encoding by means of the ongoing effort around the LISP Canonical
   Address Format (LCAF) [I-D.ietf-lisp-lcaf].

Why don't you talk about everything in terms of IP adresses and then add
a section somewhere near the end to talk about LCAF?

---

Section 1 introduces "overlay" and "underlay". I think that a certain
class of network engineer understands these concepts really well. And,
in my experience, another class has no idea what you are talking about!

This would probably show very easily on a simple diagram showing the
overlay and underlay networks.

But perhaps the summary in the Introduction is launching in a bit deep
nd fast? This is probably the hardest part of the document to write:
how do you summarise what you haven't yet talked about? There are some
bits, however, that really need work. For example...

   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.
      Furthermore EIDs are not assigned from the reserved address
      blocks.

So they have meaning only in one place, unless they have meaning in more
than one place? :-)   And what is a "resrved address block"?

---

Section 3.2

   With LISP, LISP sites (edge) and the core of the Internet are
   interconnected by means of LISP-capable routers (e.g., border
   routers) using tunnels.

I don't think this is right.

It is true that
  LISP sites and the core of the Internet are interconnected by means
  of LISP-capable routers

But the tunnels connect those border routers. So you probably need...

   LISP sites (at the edge of the Internet) are connected to the core
   of the Internet by means of LISP-capable routers (e.g., border 
   routers).  LISP sites are connected across the core of the Internet
   using tunnels between the LISP-capable routers.

---

Section 3.2

OLD

   A typically distributed database, called the Mapping System, stores
   mappings between EIDs and RLOCs.

NEW

   A database which is typically distributed, called the Mapping System,
   stores mappings between EIDs and RLOCs.

---

3.2

   Such LISP capable routers, in most cases, only require a software
   upgrade.

That's a little disconcerting. Can you add to "in most cases"?

---

4.1

   Time-To-Live (TTL):  Each mapping contains a TTL set by the ETR, upon
      expiration of the TTL the ITR has to refresh the mapping by
      sending a new Map-Request.  Typical values for TTL defined by LISP
      are 24 hours.

Presumably it doesn't *have to*. It can choose to delete it and not
refresh it. Maybe this should be worded as MUST NOT use after the 
expiration of the TTL.

---

Section 5 says

   The separation between locators and identifiers in LISP was initially
   proposed for traffic engineering purpose where LISP sites can change
   their attachment points to the Internet (i.e., RLOCs) without
   impacting endpoints or the Internet core.

RFC 6830 says 

   Creation of LISP was initially motivated by discussions during the
   IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
   October 2006 (see [RFC4984]).

RFC 4984 says

   The primary goal of
   the workshop was to develop a shared understanding of the problems
   that the large backbone operators are facing regarding the
   scalability of today's Internet routing system.

I conclude that Section 5 here is somewhat wrong.

---

Section 7.1

"the possibility for a site to issue a different mapping for each
   remote site, implementing so precise routing policies."

Suggest "the possibility for a site to support a different mapping
policy for each remote site."

---

I think some examination of the classification of normative and 
informative references would be useful.

For example, RFC 6836 is used only in 3.4.3.1 and is Normative. I think
that is fine because it is where to go for a definition of LISP+ALT. But
3.4.3.2 defines LISP-DDT by means of a reference to [I-D.ietf-lisp-ddt]
which turns out to be Informative.

---
 
Appendix A
"The LISP system.."
Haven't seen a "LISP system" defined. Suggest "The LISP architecture.."

---

Appendix A
 
"A small group of like-minded personnel from various scattered locations
within Cisco, spontaneously formed immediately after that workshop, to 
work on an idea that came out of informal discussions at the workshop
and on various mailing lists."

Suggest deleting this sentence (unless you want this to look like a 
Cisco-only initiative).

---

From: Eliot Lear <[email-masked]>
Date: Wed, 04 Mar 2015 13:37:18 +0100

Hi,

I'm sorry I didn't catch this earlier (attention elsewhere).

I would go further.  Whether LISP is a pull- or a push architecture (or
something else) is entirely a characteristic of the mapping system
used.  The one in common use today is indeed a pull architecture.  The
text discussing push/pull, therefore, should be addressed to the mapping
system.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 04 Mar 2015 13:37:18 +0100

Hi,

Eliot

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Mar 2015 09:10:20 -0800

> Suggest deleting this sentence (unless you want this to look like a 

The like-minded personnel were (and are) scattered throughout the world. And it was more than cisco folks that formed post workshop.

I agree the cisco reference should be removed.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Mar 2015 09:10:20 -0800

Dino

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 5 Mar 2015 15:29:33 +0100

Hi

Thank you very much for your very valuable comments, you can find below how
we plan to address them. Please let me know if the suggested text clarifies
them or not.

Albert

> http://datatracker.ietf.org/doc/draft-ietf-lisp-introduction/
Agreed, I´ll remove the first sentence.

> way you avoid all contention and write a document about LISP.
Agreed, I´ll remove the first paragraph and first four words of the second
paragraph.

The same reference is cited in RFC4984 and RFC4423, it is preferable to
cite it as it is or cite RFC4984?

> a section somewhere near the end to talk about LCAF?
Agreed, as you suggest I will state that EIDs and RLOCs are IP addresses,
which basically means removing the word "typically".

I also think that the text that you highlighted is sufficient to explain
that LCAF supports more general address encoding. Please let me know if
this addresses your comment.

---
> than one place? :-)   And what is a "resrved address block"?
Thanks for your comment, I suggest rephrasing the bullet point in the
following way:

EIDs have meaning only in the overlay network, which is the encapsulation
relationship between LISP-capable routers.

Then Section 3.2 mentions the EID leakage as well as its assignment.

---
>    using tunnels between the LISP-capable routers.
Agreed.

>    stores mappings between EIDs and RLOCs.
Agreed.

---
> That's a little disconcerting. Can you add to "in most cases"?
What about?

Adding LISP capabilities to routers does not mandate hardware changes and
can be done via a software upgrade.

---
> refresh it. Maybe this should be worded as MUST NOT use after the
I would prefer to avoid using the word MUST since this document does not
specify LISP. I suggest rephrasing the bullet point in the following way:

Time-To-Live (TTL):  Each mapping contains a TTL set by the ETR, upon
      expiration of the TTL the ITR can't use the mapping until it is
refreshed by
      sending a new Map-Request.  Typical values for TTL defined by LISP
      are 24 hours.

---
> I conclude that Section 5 here is somewhat wrong.
I suggest the following sentence:

The separation between locators and identifiers in LISP was initially
motivated by discussions during the IAB-sponsored Workshop, the outcomes
are
described in RFC4984.

---
> policy for each remote site."
Agreed.

> which turns out to be Informative.
Agreed, I´ll move the following references from Informative to Normative.
[I-D.ietf-lisp-ddt]
[I-D.ietf-lisp-lcaf]
[I-D.ietf-lisp-sec]
[I-D.ietf-lisp-threats]

---
> Haven't seen a "LISP system" defined. Suggest "The LISP architecture.."
Agreed.

> Suggest deleting this sentence (unless you want this to look like a
Agreed, thanks!

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

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 5 Mar 2015 15:29:33 +0100

Hi

Albert

---

---
Agreed.

Agreed.

---
What about?

---

---

---
Agreed.

---
Agreed.

Agreed, thanks!

---

From: Brian Haberman <[email-masked]>
Date: Thu, 05 Mar 2015 09:38:30 -0500

Hi Albert,

> cite it as it is or cite RFC4984?

My personal opinion is that RFC 4984 would be a perfectly reasonable
reference for this.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 05 Mar 2015 09:38:30 -0500

Hi Albert,

Regards,
Brian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Mar 2015 20:02:05 -0000

Hello Albert,

Thanks for your speedy turn-around.

>> You will be aware of RFC 5291 and the use of ORF to make BGP a pull-
>> mode protocol.
>>
>> (I won't say to you that LISP is push mode because a Map-Reply
>> pushes the mapping information from the map server to the client :-)
>>

Perfect
 
> Agreed, I´ll remove the first paragraph and first four words of the 
> second paragraph.

Also perfect.
 
>> COMMENT:

Please note that Comments are just my observations. You are not obliged to make changes or pay attention. You just need to reach equilibrium with your AD.

> The same reference is cited in RFC4984 and RFC4423, it is preferable
> to cite it as it is or cite RFC4984?

Per Brian, 4984 would be fine.
 
>> Neither of which offers any possibility to vary "always" into
>> "typically".
>>
>> The again, 3.2 has...
>>
>>    EIDs are typically -but
>> Some consistency is needed!
>>
> Agreed, as you suggest I will state that EIDs and RLOCs are IP addresses, which
> basically means removing the word "typically". 

Why don't you say "addresses" instead of "typically IP addresses"? That is then open to the flexibility of LCAF while still embracing IP addresses.

> I also think that the text that you highlighted is sufficient to explain that
> LCAF supports more general address encoding. Please let me know if this
> addresses your comment. 

I think it would *if* you make the change to "addresses". 

>> and fast? This is probably the hardest part of the document to write:
>> than one place? :-)   And what is a "reserved address block"?
>
> Thanks for your comment, I suggest rephrasing the bullet point in the following way:
>

A fine change.
Note that you are addressing my specific example, giving a little bit more of a clue about what an overlay is, but not handling the general problem that the Introduction may be going to deep, or fully explaining overlay/underlay.

[snipped agreement]

> Adding LISP capabilities to routers does not mandate hardware changes
> and can be done via a software upgrade.  

If that's true (and I have no reason to doubt you), then that works.

> I would prefer to avoid using the word MUST since this document
> does not specify LISP.

Agreed. My bad choice of emphasis marker!

> I suggest rephrasing the bullet point in the 
> following way:
>
>      expiration of the TTL the ITR can't use the mapping until it is refreshed by 

That works.

>> Section 5 says
[snip]
> motivated by discussions during the IAB-sponsored Workshop, the outcomes are 
> described in RFC4984. 

Great.
s/are/of which/

[snipped agreement]

Many thanks again for the work.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 6 Mar 2015 20:02:05 -0000

Hello Albert,

Perfect

Also perfect.

 

A fine change.

[snipped agreement]

That works.

[snip]

Great.
s/are/of which/

[snipped agreement]

Adrian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Mar 2015 15:18:46 -0500

Hi All,

On 3/6/15 3:02 PM, Adrian Farrel wrote:

>>> Section 1
>>> 
>>> I'm really not comfortable with your text... "Indeed and as
>>> pointed out by the unpublished Internet Draft by Noel Chiappa
>>> [Chiappa]"
>>> 
>>> This isn't a stable reference and I don't think you need it.
>>> You could either rely on the later reference to RFC 4984,
>>> reference RFC 6830 itself, or take out the aside "and as... ...
>>> [Chiappa]"
>>> 
>> The same reference is cited in RFC4984 and RFC4423, it is
>> preferable to cite it as it is or cite RFC4984?
> 

Good.

> 
>>> Section 1 has
>>> 
>>> LISP creates two separate namespaces, EIDs (End-host
>>> IDentifiers) and RLOCs (Routing LOCators), both are typically
>>> syntactically identical to the current IPv4 and IPv6
>>> addresses.
>>> 
>>> RFC 6830 explains this in the definitions of EID, but seems to
>>> be clear that an RLOC is an IP address.
>>> 
>>> If you are opening up the RLOC to be something other than an IP
>>> address (a MAC address or even something else?) then how do you
>>> deal with: - lack of ICMP - non-uniqueness
>>> 
>>> Possibly you can say that this is "not my problem" since the
>>> problem would already exist in the routing system that handles
>>> the non-IP addresses. But maybe, for an introduction to the
>>> topic this is over- reaching towards the many potential
>>> applications rather than the basic explanation of the
>>> architecture?
>>> 
>>> Endpoint IDentifier (EID):  EIDs are IPv4 or IPv6 addresses
>>> used to uniquely identify nodes irrespective of their
>>> topological location and are typically routed intra-domain.
>>> 
>>> Routing LOcator (RLOC):  RLOCs are IPv4 or IPv6 addresses
>>> assigned topologically to network attachment points and
>>> typically routed inter-domain.
>>> 
>>> EIDs are typically -but not limited to- IPv4 or IPv6 addresses
>>> 
>>> ...and...
>>> 
>>> With LISP, the core uses RLOCs, an RLOC is typically -but not
>>> limited to- an IPv4 or IPv6 address
>>> 
>>> Typical mappings in LISP bind EIDs in the form of IP prefixes
>>> with a set of RLOCs, also in the form of IPs.  IPv4 and IPv6
>>> addresses are encoded using the appropriate Address Family
>>> Identifier (AFI) [RFC3232].  However LISP can also support more
>>> general address encoding by means of the ongoing effort around
>>> the LISP Canonical Address Format (LCAF) [I-D.ietf-lisp-lcaf].
>>> 
>>> Why don't you talk about everything in terms of IP adresses and
>>> then add a section somewhere near the end to talk about LCAF?
>> 
>> Agreed, as you suggest I will state that EIDs and RLOCs are IP
>> addresses, which basically means removing the word "typically".
> 
> Why don't you say "addresses" instead of "typically IP addresses"?
> That is then open to the flexibility of LCAF while still embracing
> IP addresses.

This makes sense to me.

> 
>> I also think that the text that you highlighted is sufficient to
>> explain that LCAF supports more general address encoding. Please
>> let me know if this addresses your comment.
> 

Agreed.

> 
>>> Section 1 introduces "overlay" and "underlay". I think that a
>>> certain class of network engineer understands these concepts
>>> really well. And, in my experience, another class has no idea
>>> what you are talking about!
>>> 
>>> This would probably show very easily on a simple diagram
>>> showing the overlay and underlay networks.
>>> 
>>> But perhaps the summary in the Introduction is launching in a
>>> bit deep and fast? This is probably the hardest part of the
>>> document to write: how do you summarise what you haven't yet
>>> talked about? There are some bits, however, that really need
>>> work. For example...
>>> 
>>> o  EIDs have meaning only in the overlay network unless they
>>> are leaked into the underlay network.  The overlay is the 
>>> So they have meaning only in one place, unless they have
>>> meaning in more than one place? :-)   And what is a "reserved
>>> address block"?
>> 
>> EIDs have meaning only in the overlay network, which is the
> A fine change. Note that you are addressing my specific example,
> giving a little bit more of a clue about what an overlay is, but
> not handling the general problem that the Introduction may be going
> to deep, or fully explaining overlay/underlay.
> 
> [snipped agreement]
> 
>>> 3.2
>>> 
>>> Such LISP capable routers, in most cases, only require a
>>> software upgrade.
>>> 
>> Adding LISP capabilities to routers does not mandate hardware
>> changes and can be done via a software upgrade.
> 

Based on Alia's review, this whole sentence will be gone.

> 
>>> 4.1
>>> 
>>> Time-To-Live (TTL):  Each mapping contains a TTL set by the
>>> ETR, upon expiration of the TTL the ITR has to refresh the
>>> mapping by sending a new Map-Request.  Typical values for TTL
>>> defined by LISP are 24 hours.
>>> 
>>> Presumably it doesn't *have to*. It can choose to delete it and
>>> not refresh it. Maybe this should be worded as MUST NOT use
>>> after the expiration of the TTL.
>> 
>> I suggest rephrasing the bullet point in the following way:
>> 
>> Time-To-Live (TTL):  Each mapping contains a TTL set by the ETR,
>> upon expiration of the TTL the ITR can't use the mapping until it
>> is refreshed by sending a new Map-Request.  Typical values for
>> TTL defined by LISP are 24 hours.
> 
> That works.

Agreed.

>> The separation between locators and identifiers in LISP was
>> initially motivated by discussions during the IAB-sponsored
>> Workshop, the outcomes are described in RFC4984.
> 
> Great. s/are/of which/
> 

Agreed.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 06 Mar 2015 15:18:46 -0500

Hi All,

Good.

This makes sense to me.

Agreed.

Agreed.

Agreed.

Regards,
Brian

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 9 Mar 2015 13:23:59 +0100

Hi

Thanks for your comment, I agree with you, in some cases (e.g., NERD) LISP
can operate as a push architecture. We used the term pull arcihtecture to
introduce the use of RLOC probing, please let me know if the following
paragraph clarifies the point that you rised:

In most cases LISP operates with a pull-based Mapping System (e.g., DDT),
this results in an edge to edge pull architecture. In such scenario the
network state is stored in the control-plane while the data-plane pulls it
on demand.  This has consequences concerning the propagation of xTRs
reachability/liveness information since pull architectures require explicit
mechanisms to propagate this information.  As a result LISP defines a set
of mechanisms to inform ITRs and PITRS about the reachability of the cached
RLOCs:

Albert

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 9 Mar 2015 13:23:59 +0100

Hi

Albert

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Mar 2015 13:24:55 +0100

Hi Albert,

While that text works, the key point to make is that it is a matter for
the mapping system.

Eliot

On 3/9/15 1:23 PM, Albert Cabellos wrote:
> Hi
>
> Thanks for your comment, I agree with you, in some cases (e.g., NERD)
> LISP can operate as a push architecture. We used the term pull
> arcihtecture to introduce the use of RLOC probing, please let me know
> if the following paragraph clarifies the point that you rised:
>
> In most cases LISP operates with a pull-based Mapping System (e.g.,
> DDT), this results in an edge to edge pull architecture. In such
> scenario the network state is stored in the control-plane while the
> data-plane pulls it on demand.  This has consequences concerning the
> propagation of xTRs reachability/liveness information since pull
> architectures require explicit mechanisms to propagate this
> information.  As a result LISP defines a set of mechanisms to inform
> ITRs and PITRS about the reachability of the cached RLOCs:
>
> Albert
>
>
> On Wed, Mar 4, 2015 at 1:37 PM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     pushes
>     [email-masked] <mailto:[email-masked]>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Mar 2015 13:24:55 +0100

Hi Albert,

Eliot