Subject: [lisp] draft-ietf-lisp-introduction-04 (Part 1)

From: Ronald Bonica <[email-masked]>
Date: Wed, 6 Aug 2014 17:58:18 +0000

Folks,

The following are a few comments regarding draft-ietf-lisp-introduction-04. Expect further comments in the next few days.

- Section 1 adds no value. I agree with the editor's suggestion to remove.

- Section 2 is empty. So clearly, I agree with the editor's suggestion to remove.

- Section 3 contains a few broken definitions. But sooner or later, you will need a Glossary. So, I disagree with the editor's suggestion to remove the entire section. Please change the name of this section from "Initial Glossary" to "Glossary" or "Terminology". Then delete its contents. Then import whatever definitions you need, verbatim, from RFCs 6830-6836. This should cover most of the terminology that you need. It will also prevent you from redefining words. If you find that you still need to define a few terms, please do so.

- Section 4 adds no value. I agree with the editor's suggestion to remove.

- Section 5 adds no value. I agree with the editor's suggestion to remove.

- Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same sense that MPLS does. It's quite different.

- Section 7.4 adds no value. I agree with the editor's suggestion to remove.

- Section 7.5 is not in charter. I agree with the editor's suggestion to remove.

- Section 7.7 is not in charter. I agree with the editor's suggestion to remove.

- Section 7.8 adds no value. I agree with the editor's suggestion to remove.

- Appendix A is redundant with Section 3. I agree with the editor's suggestion to remove

- Appendix B contains interesting information, but does not contribute to the goals of the draft. I agree with the editor's suggestion to remove it.

- Please add a short "Introduction" before the Glossary. It should read as follows:

"The Internet is experiencing problems A, B and C. LISP solves this problem by doing D, E and F. LISP will solve A, B and C because [....]

   D, E, and F distinguish LISP from existing routing protocols. The architectural tradeoffs associated with D, E and F are [....]. 

Standby for more comments.

Ron Bonica

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 7 Aug 2014 17:27:16 +0200

Hi Ron,

Thanks for your comments, please see my reply below:

> - Section 3 contains a few broken definitions. But sooner or later, you will need a Glossary. So, I disagree with the editor's suggestion to remove the entire section. Please change the name of thi…

Agreed, we should use the terminology as defined in RFCs 68030-6836.
This will actually make the rest of the RFCs easier to read, one of
the goals of LISP-INTRO.

> - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same sense that MPLS does. It's quite different.

RFC6830 states that LISP offers TE.

Albert

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

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 11 Aug 2014 15:40:39 +0000

Hi Albert,

LISP solves one part of the TE problem. That is, it allows the ITR to choose the ETR through which traffic enters the destination LISP site. However, it doesn't determine the path that traffic takes between IETR and ETR. So, it that sense, LISP TE is different from traffic engineering with MPLS.

Also, I am not sure that it is *always* a good idea to let the ITR choose the ETR through which traffic enters the destination LISP site. A discussion of when this is and isn't a good idea might be appropriate in the intro document.

                                                                   Ron

> > - Section 7.3 needs to be rethought. LISP doesn't provide TE, in the same
> sense that MPLS does. It's quite different.
> >
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 11 Aug 2014 09:00:21 -0700

> LISP solves one part of the TE problem. That is, it allows the ITR to choose the ETR through which traffic enters the destination LISP site. However, it doesn't determine the path that traffic take…

Read draft-farinacci-lisp-te Ron. A path CAN be chosen. And it is a super-set of functionality that MPLS-TE provides.

> Also, I am not sure that it is *always* a good idea to let the ITR choose the ETR through which traffic enters the destination LISP site. A discussion of when this is and isn't a good idea might be…

The intro document should not be subjective. We should have learned from previous mistakes on this topic.

Dino

---

From: Ronald Bonica <[email-masked]>
Date: Mon, 11 Aug 2014 16:46:16 +0000

Dino,

I am not convinced that draft-farinacci-lisp-te provides a superset of the functionality provided by MPLS-TE. A more accurate statement would be to say that it provides a partially overlapping set of functionality.

That said, I think that it is possible to avoid the entire argument not using the words "Traffic Engineering". A better approach would be to describe what LISP offers in this area, explicitly, in a few paragraphs.

                                                                                                                   Ron

> -----Original Message-----
> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Monday, August 11, 2014 12:00 PM
> To: Ronald Bonica
> Cc: Albert Cabellos; LISP mailing list list
> Subject: Re: [lisp] draft-ietf-lisp-introduction-04 (Part 1)
> 
> 
> > Hi Albert,
> >
> > LISP solves one part of the TE problem. That is, it allows the ITR to choose
> the ETR through which traffic enters the destination LISP site. However, it
> doesn't determine the path that traffic takes between IETR and ETR. So, it
> that sense, LISP TE is different from traffic engineering with MPLS.
> 
> > Also, I am not sure that it is *always* a good idea to let the ITR choose the
> ETR through which traffic enters the destination LISP site. A discussion of
> when this is and isn't a good idea might be appropriate in the intro
> document.
>