[apps-discuss] Review of draft-lear-lisp-nerd-08

S Moonesamy <sm+ietf@elandsys.com> Tue, 10 April 2012 22:06 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C460511E813A for <apps-discuss@ietfa.amsl.com>; Tue, 10 Apr 2012 15:06:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level:
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPxeqf1BzJO6 for <apps-discuss@ietfa.amsl.com>; Tue, 10 Apr 2012 15:06:11 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF13F11E812C for <apps-discuss@ietf.org>; Tue, 10 Apr 2012 15:06:10 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([41.136.235.8]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q3AM5trp017854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 15:06:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1334095568; i=@elandsys.com; bh=28+V5rDsspWAvUYCZoorrhyjMTxhNj8yUit/36dsDxU=; h=Date:To:From:Subject:Cc; b=QAM5fIc/RtPy9r1aREQJM07JPFIqvOnj4CZ2MfeY2u9Lyj3+QUwepgBQRINnx8sUg 4NSK4QatumphjkWPWtrn+RWqUf8sN80Wb0TZ9bv8ZZxllLfCw6VTg0acZsoONd/8uW yeUQGN0M+i8H+gyqnEyDqN3/fwNmr104VyMQKu9U=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1334095568; i=@elandsys.com; bh=28+V5rDsspWAvUYCZoorrhyjMTxhNj8yUit/36dsDxU=; h=Date:To:From:Subject:Cc; b=Pg+kvhw2KRmxxxYveM/U8Mx4vuwGS2bTIELu/hCWrNXhFfP61kKgY9ke0o2sQjA6H 6BTNB98SlZ6UZOZ9Fv1B0cClqyfZoff/8cwGn+MypkiBq+GeYeceB9NDudXddZCfy+ Qa2qmMZ6LqIP3gWxxg2Slhi4kJ6kdp9H+oYudpIs=
Message-Id: <6.2.5.6.2.20120410125815.08d5c788@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 10 Apr 2012 14:58:13 -0700
To: Eliot Lear <lear@cisco.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Review of draft-lear-lisp-nerd-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 22:06:15 -0000

Hi Eliot,

draft-lear-lisp-nerd-08 presents an experimental database and a 
discussion of methods to transport the mapping of EIDs to RLOCs to 
routers in a reliable, scalable, and secure manner.  It does not 
conflict with any work currently being done in the Applications 
Area.  Given that it is an Independent Submission, these comments are optional.

Overall, the draft was an interesting read.  I don't the LISP 
background to perform an adequate review.  I skipped the lengthy 
References section due to lack of time.

In Section 2:

  "Operational functions are split into two components: database updates
    and state exchange between ITR and ETR during a communication."

I suggest expanding ITR and ETR on first use.

In Section 2.1:

   "A NERD is generated by an authority that allocates provider
    independent (PI) addresses (e.g., IANA or an RIR) which are used
    by sites as EIDs."

According to draft-ietf-lisp-06 (Section 3), PI addresses are assigned.

In Section 2.3:

   "Each region runs a database authority.  In this case, provider
    independent address space is allocated to either Regional Internet
    Registries (RIRs) or to affiliates of such organizations of
    network operations guilds (NOGs)."

I am at a loss here.  The draft is talking about PI addresses for a 
region.  Such assignments are generally through RIRs and NIRs and not 
through NOGs.  Shouldn't the paragraph be discussing about 
registration of entries on a regional basis without resorting to an 
apex (see previous paragraph).?

In Section 3:

  "The database name is an ASCII-encoded domain name, as specified in
   [RFC5321]"

Where is that specified in RFC 5321?

  "This is the name that will appear in the Subject field of
   the certificate used to verify the database."

I suggest taking a look at RFC 6125, specifically Section 2.3.

In Section 4.2:

   "This begs the question: how does a router know to retrieve version
    1105450 in our example above?  It cannot.  A redirect must be given
    by the server to that URI when the router attempts to retrieve
    differences from the current version, say, 1105503."

I understand what you mean.  Some readers might consider the above as 
underspecified.

In Section 5.4.1:

   "One possible method of doing this is provided in [RFC4108]"

Section 3 mentions that Cryptographic Message Syntax was not used as 
it is not widely deployed.  Doesn't RFC 4108 require CMS?

In Section 7:

   "Good old NNTP [RFC0977] itself provides two separate mechanisms
   (one push and another pull) to provide a coherent update process."

RFC 3977 obsoletes RFC 977.

In Section 7.1:

    "While the administrative lines may appear to be correct, the
     location of name servers may not be.  If name servers sit within
     PI address space, thus requiring LISP to reach, a circular
     dependency is created."

Wouldn't the service used to resolve the domain names, e.g. for HTTP, 
also sit within PI address space?  The problem (discussed in Section 
8.1) would also apply to any protocol that relies on DNS.

The little gem in the draft is 'The format of the AFI is specified by 
IANA as "Address Family Numbers"'.

Regards,
S. Moonesamy