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

[Brian Haberman <[e-mail]>]

Hi Dino,

On 1/14/15 1:10 PM, Dino Farinacci wrote:
> 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
>> <[e-mail]> 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.?
> 
> I will yield to the authors.
> 
>> * 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.

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

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

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

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

> 
> Plus, it raises questions more than simplifies the understanding of
> LISP. This is an intro document.
> 
>> * 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?
> 
> We are encouraging SSM but an (RP-EID, G) can be used as well. RFC
> 6831 describes all PIM modes.

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

Regards,
Brian