Locator/ID Separation Protocol (lisp)

Brian Haberman | 14 May 2013 19:37

AD Evaluation: draft-ietf-lisp-deployment

All,
      I have completed my AD Evaluation of draft-ietf-lisp-deployment. 
I have some comments/questions that need to be resolved before we can 
move the document along to an IETF Last Call.

1. The document leverages several terms that are not defined in this 
document.  It would be useful to point out where those terms are 
defined.  Terms that I came across that should be referenced (or defined 
locally) are: map-and-encap, Loc-Status-Bits, PoPs, and path stretch.

2. Introduction

* s/(LISP) addresses the/(LISP) is designed to address the/

* s/LISP go beyond of just/LISP go beyond just/

* s/the draft we/the document we/

* I see variations of "LISP site" within the document (LISP site, LISP 
Site, LISP end site).  Please pick one term and make it consistent.

* The lead-in text to the definition of "LISP site" has no mention of 
the definition of "Network element".  It would be useful to say that the 
document is defining two new terms.

* s/is connected connected to/is connected to/

3. Section 2

* s/is called Tunnel Router/is called a Tunnel Router/

(Continue reading)

headers

Isidoros Kouvelas | 14 May 2013 17:13

Isidor todo week May 14th


- Disjoint RLOCs. Code reviewing Johnson's diff, design discussions,
  pick up and finish code when Johnson goes on PTO on Wednesday.

- Sync with Nalin and Jesper on L2 Interface and LISP adjacency
  management for Campus. Sanjay has offered an engineer for a
  month and we need to provide initial input.

- Start on L2 AFI support LISP control plane design with Jesper.

- Try to find time to move forward with database redist from RIB.

- Bugs + double commit CSCue85804 to a gazilion CEF branches.

headers

Joel M. Halpern | 6 May 2013 17:45

draft-ietf-lisp-threats

My apologies for not getting to this issue soone.

The approach being taken in this version of the document seems to me to 
be ineffective.  As a simple example, section 5.2 says that EID-to-RLOC 
cache Threats are Severity level 2, meaning that it can be dealt with by 
turning off certain features in pubic deployments.
But it is then followed by a LISP of threats, and a set of points to 
features in section 6 and 6.3.  As a result I can not tell what features 
would need to be turned off to address the threat of section 5.2.

I am very concerned by declaring that folks should turn off echo-nonce. 
  Echo-none was added, for use in public deployments, fo good reasons. 
Changing the recommendations in this regard is fairly major.

This leads to a general issue about Severity Level 2.  Across the 
document, different features are recommended to be turned off.  As a 
reader, it is very easily to lose track of the collective effect.  If we 
are going to stick with this approach, I think we need to pull up the 
list of problematic features to the front of the document.  We need to 
clearly state that based on the analysis below, features X, Y, and Z are 
not recommended for public deployments of LISP.
And then the WG has to decide whether that is a recommendation we can 
support.
(Yes, I think we would be well-served putting this in the front of the 
document, rather than in the security considerations section.)

In the description of section 5.4.4 of Instance ID bits, I do not 
understand how an ACL could help.  I can not see folks configuring 
firewalls for the set of EIDs permitted within the VPN.  Such a 
configuration would counter the very ease of deployment associated with

(Continue reading)

headers

johnsonhammond1 | 27 Apr 2013 19:43

Biggest Fake Conference in Computer Science

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See

(Continue reading)

headers

Wassim Haddad | 27 Apr 2013 07:34

Shepherd writeup for draft-ietf-lisp-deployment-07

Dear all,

I am the document shepherd for draft-ietf-lisp-deployment-07. In order for me to complete the shepherd writeup, I would like first to ask the authors and the WG if any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

Regards,

Wassim H.

_______________________________________________
lisp mailing list
lisp <at> ietf.org
https://www.ietf.org/mailman/listinfo/lisp

headers

Dino Farinacci | 27 Mar 2013 00:25

Re: draft-arango-pim-join-attributes-for-lisp

> Dino,
> 
> One reason for two attributes is flexibility. For example, You could send
> the receiver RLOC attribute on the upstream neighbor field, and the
> transport mode attribute on each individual source. This would allow
> requesting multicast transport for some sources and unicast transport for
> others without having to repeat the receiver RLOC address for each source.
> 
> Jesus

Okay, thanks for the response Jesus. That makes perfect sense.

Dino

> 
> 
> 
> 
> On 3/22/13 3:55 PM, "Dino Farinacci" <farinacci <at> gmail.com> wrote:
> 
>>> We would like to see some discussion on the list for
>>> draft-arango-pim-join-attributes-for-lisp. The LISP multicast
>>> specification in RFC6831 defaults to the use of a multicast transport
>>> over RLOC space. The draft introduces two new attributes to PIM
>>> signaling to support unicast transport with ingress replication. Slides
>>> describing the proposal can be found at:
>>> http://www.ietf.org/proceedings/86/slides/slides-86-lisp-8.pptx
>> 
>> I have one question and one comment.
>> 
>>> Unicast transport requires the communication of two additional pieces
>>> of information in the PIM(S-EID,G)Join message:
>>> 
>>> 1) An indication that the receiver-ETR wants unicast transport and is
>>> not additionally joining through native multicast by sending an
>>> (S-RLOC,G) Join.
>>> 
>>> 2) The receiver-ETR RLOC address that should be used as the destination
>>> for the LISP unicast encapsulated multicast data packets.
>> 
>> Why can't the two pieces of information be transmitted in one attribute.
>> Because in both cases, the ETR would be indicating how it wants to
>> receive encapsulated multicast packets. If the ETR supplies a unicast
>> RLOC, then it should be implicit that the ETR wants the encapsulation via
>> unicast and if the ETR supplies a delivery-group address it should should
>> also join with the deliver-group into the underlay.
>> 
>> And the comment, even if the ETR supplies a delivery-group and does join
>> the underlay, packets encapsulated in multicast may still not reach the
>> ETR. So to generally solve this problem, there needs to be more machinery
>> so the ETR can tell if there is multicast connectivity (per
>> address-family) from the ITR.
>> 
>> Dino
>

headers

Paul Vinciguerra | 24 Mar 2013 23:13

Multicast LISP

I know I’m showing up late to the party, but can someone expand upon this from the RFC?

5. Source Addresses versus Group Addresses

Multicast group addresses don't have to be associated with either the

EID or RLOC namespace. They actually are a namespace of their own

that can be treated as logical with relatively opaque allocation.

So, by their nature, they don't detract from an incremental

deployment of LISP-Multicast.

The documents make reference to:

(S-EID,G)

(S-RLOC,G)

It seems that while both these may be numerically identical (eg. 239.255.255.254), in terms of LISP, doesn’t (S,G) have to much more complex and represent either (S-EID,G-EID(IID)) and (S-RLOC,G-RLOC(IID))?

Once we introduce LISP mobility, what does (G) actually mean, especially when (G) can refer to link-local multicast for a host that has roamed off of its home subnet?

Paul

_______________________________________________
lisp mailing list
lisp <at> ietf.org
https://www.ietf.org/mailman/listinfo/lisp

headers

Sharon Barkai | 22 Mar 2013 22:29

Lisp for SDN

Fellow Lispers,

Was good to meet last week and hear the presentations that demonstrate the "deep-ness" of the lisp threat
analysis, the serious push for formal identity networking / address space, and what Dino demonstrated as
the ease in which redundantly complex multicast signaling is shed in favor of simple mapping and overlay
aggregation or 2tier networks. This lisp signaling-less ability is a great strength and facilitates the
move from protocols to schemas.

Would like however to point 3 of the efforts we did not cover:

1) NVO Gap Analysis: last week it was clear that NVO wg realized that whenever there is an overlay there is
also an underlay, and, that underlay can be used to build a global mapping service NVO called IMA (which
means mother in Hebrew :)

I think it's key that as the most mature distributed overlay lisp will make its mark on NVO .. especially
since most serious SDN architectures are (justly) converging towards distributed overlays.

2) the SHDHT proposal: basically any contribution that can facilitate super flat mapping performance for
exposing detail identity and affinity mapping is great step. Even if some of these mappings can only be
used in an intra-provider.

3) last, the lisp4nfv I was going to cover. Not sure if anyone caught the etsi NFV presentation in David's
SDNRG session.

Basically a very large group of carriers plan a full isomorphism between the physical reality of
functional-devices to a virtual reality of functional VMs. This group clearly did not internalize the
gap between overlay virtualization and vlan/vpn presented in nvo3, nor realize the maturity if lisp as an
nvo suite.

Anyway, thanks for reading and sorry for the long speech, hopefully we can catch up to these orthogonal
domains by next ietf.

Sent from my iPhone 650 492 0794

headers

Isidoros Kouvelas | 21 Mar 2013 11:40

draft-arango-pim-join-attributes-for-lisp

Hello,

We would like to see some discussion on the list for draft-arango-pim-join-attributes-for-lisp. The
LISP multicast specification in RFC6831 defaults to the use of a multicast transport over RLOC space. The
draft introduces two new attributes to PIM signaling to support unicast transport with ingress
replication. Slides describing the proposal can be found at:
http://www.ietf.org/proceedings/86/slides/slides-86-lisp-8.pptx

Unicast transport requires the communication of two additional pieces of information in the
PIM(S-EID,G)Join message:

1) An indication that the receiver-ETR wants unicast transport and is not additionally joining through
native multicast by sending an (S-RLOC,G) Join.

2) The receiver-ETR RLOC address that should be used as the destination for the LISP unicast encapsulated
multicast data packets.

The draft is introducing the "Transport" and "Receiver RLOC" PIM Join/Prune attributes to carry the
additional required information in LISP encapsulated (S-EID,G) Join/Prune PIM messages.

The draft was presented in Orlando in the PIM working group but due to agenda time limitations it was not
presented in LISP. The conclusion in the PIM WG is that they have no problem in adopting the draft as long as
the LISP WG thinks that it makes sense and is useful. We are therefore looking for input to move this forward.

Note that the draft is incorrectly labeled as standards track. It will be fixed to reflect that it is
experimental in the next revision.

thanks
Isidor

headers

internet-drafts | 20 Mar 2013 11:48

I-D Action: draft-ietf-lisp-deployment-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.

	Title           : LISP Network Element Deployment Considerations
	Author(s)       : Lorand Jakab
                          Albert Cabellos-Aparicio
                          Florin Coras
                          Jordi Domingo-Pascual
                          Darrel Lewis
	Filename        : draft-ietf-lisp-deployment-07.txt
	Pages           : 24
	Date            : 2013-03-20

Abstract:
   This document discusses the different scenarios for the deployment of
   the new network elements introduced by the Locator/Identifier
   Separation Protocol (LISP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-deployment

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-lisp-deployment-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-deployment-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

headers

Damien Saucez | 15 Mar 2013 14:55

Need comments on LISP Threats Analysis

Dear all,

As requested by chairs in today's meeting we would like to ask you to
comment on the threats analysis.

Here are the there questions that must be precisely answered by you:

1. are the 4 severity levels well defined? (do you see intermediate levels?)

2. do you agree with the level of severity given for each threat (yes/no/why)?

3. if a feature has to be deactivated, do you agree for having it deactivated?

Thank you.

Damien Saucez

10	May 2013
5	April 2013
157	March 2013
61	February 2013
108	January 2013
23	December 2012
89	November 2012
70	October 2012
24	September 2012
52	August 2012
36	July 2012
8	June 2012
7	April 2012
30	March 2012
36	February 2012
12	January 2012
24	December 2011
16	November 2011
52	October 2011
74	September 2011
11	August 2011
136	July 2011
81	June 2011

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31