Opened 10 years ago

Last modified 10 years ago

#29 new editorial

Editorial Issues Section 2 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review

Reported by: luigi@… Owned by:
Priority: trivial Component: draft-ietf-lisp
Severity: - Keywords:
Cc:

Description (last modified by luigi@…)

Section 2 states “More cost-effective multi-homing” but it is not
stated what is actually meant by this statement and why the Loc/ID
scheme as proposed would make multi-homing cost-effective.

Section 2 states “Mobility without address changing” but then “… or
acquiring a new address based on the new network location.” These
statements are contradicting each other.

Section 2 states “This draft describes protocol mechanisms to achieve
the desired functional separation.” But separation between which
functions ? If this statement is related to the separation between
forwarding and control/routing, then it is defeated looking at i) the
way RLOC reachability testing inter-twin control as part of the
forwarding plane, and ii) the use of “Data Probes” forwarding date as
part of the control plane of TR’s.

Section 2 the statement “This draft attempts to not compete or overlap
with such solutions and the proposed protocol changes are expected to
complement a host-based mechanism when Traffic Engineering
functionality is desired.” raises the question if these solutions
would still be complementary if TE functionality is not desired (this
is not clearly stated in the document). On the other hand, the
statement “Building the solution into the network will facilitate
incremental deployment of the technology on the Internet.” should be
further developed to explain why “network deployment” is considered as
facilitating incremental deployment ?

Section 2 states “Some of the design goals of this proposal include:”
Which are the other goals ? there is only partial match with the
design goals specified at RRG (the term “design goal” seems to have a
different meaning) and it is unclear what changes are referring
to. The statement “Minimize required changes to Internet
infrastructure.” is vague. The statement “most customer site routers”
under which condition the remaining fraction would have to change.

Section 2 describes LISP variants depending on EID “routability” it
would be appropriate to state “routability” refers to the core
i.e. between ITR/ETR (as EID remain routable in “sites” otherwise
there is no difference with host-based solutions)

Section 2. LISP 1.5 is assumed to make use of a “separate topology”
also referred to as “alternative topology”. The key question is what
is this topology ?

Section 2. LISP 3 assumes the existence of EID-to-RLOC database. How
the existence of the databases is made aware to ITR. This is what
determines the use of Data probes vs Map requests if both modes are
supported.

Change History (2)

comment:1 Changed 10 years ago by luigi@…

  • Description modified (diff)
  • Summary changed from Editorial Issues Section 2 raised by Dimitri Papadimitriou reviewing draft-ietf-lisp-06.txt to Editorial Issues Section 2 of draft-ietf-lisp-06.txt raised by Dimitri Papadimitriou in his review

comment:2 Changed 10 years ago by luigi@…

  • Priority changed from minor to trivial
Note: See TracTickets for help on using tickets.