Folks,
Version 07 of this draft is vastly improved over Version 03. Thanks for this
good work!
However, Version 07 of this document ignored much of the input offered on
version 05. Therefore, it is not ready for submission to the IESG.
The following are areas that still remain to be addressed:
Section 1:
- Although Section 1 talks around the issue, it does not explicitly
state the degree to which LISP decouples locator semantics from identifier
semantics. This could probably be remedied with a short bullet list. The list
should include statements like the following:
o RLOCs have meaning only in the underlay network
o EIDs have meaning only in the overlay network, unless they are leaked into
the underlay network
o The LISP edge (xTR) maps EIDs to RLOCS
o Within the underlay network, RLOCs have both locator and identifier
semantics
o An EID within a LISP site carries both identifier and locator semantics to
other nodes within that site
o An EID within a LISP site carries identifier and limited locator semantics
to nodes at other LISP sites (i.e., enough locator information to tell that the
EID is external to the site)
o The relationship described above is not unique. L3VPN relationships
maintain the same relationship between IPv4VPN addresses and IP addresses
Section 3.1:
- Section 3.1 fails to mention that LISP does not maintain isolation
between the forwarding and control planes. (That is, in LISP, forwarding plane
activity routinely causes activity on the control plane). This omission is
serious in itself. However, Section 3.1 amplifies the seriousness of this claim
by stating that LISP decouples the forwarding and control planes.
- Section 3.1 fails to mention LISP's most salient characteristics.
These are:
o That the ITR maintains only a subset of the mapping table
o That the ITR does not maintain a "default mapping" (i.e., a mapping to a
hub that would forward all otherwise unmapped traffic)
o That the ITR pulls routes. This is to be contrasted with a push model (e.g.
BGP without ORF) and a push-pull model (BGP with ORF)
Section 4.1
The benefit of maintaining only a subset of the mapping table is that you
conserve memory on the XTR. However, this benefit is tempered. When a XTR
requests a mapping for an EID, it must receive the most specific mapping for
that EID plus all mappings that are covered by that mapping.
A consequence of not maintaining a default route is that an ITR will drop the
first few packets destined to a prefix.
Also as a consequence of the pull model, LISP requires additional protocol
support to solve the problem of mapping staleness. In order to address this
problem, the ITR refreshes routes periodically. However, there is a tradeoff.
If the xtr refreshes routes too frequently, it burdens the control plane. If it
does not refresh routes frequently enough, forwarding suffers. In order to
solve this problem, the LISP forwarding plane provides feedback to the control
plane. Processing this feedback consumes computational resources. It also
presents security issues that may prevent the feedback mechanism from being
deployed on the global Internet.
Section 4.2:
A consequence of the pull model is that LISP requires additional protocol
support to solve the problem of ETR liveness. This protocol support can take
the form of feedback from the forwarding plane or ETR probing. For security
reasons, forwarding plane feedback mechanisms must be disabled when LISP is
deployed on the global Internet. Therefore, LISP becomes increasingly dependent
upon ETR probing, which may not scale well
Section 3.5:
- Section 3.5 should mention how PITRs will impact the size of global
routing tables during the LISP transition period, particularly of EIDs cannot
be aggregated before advertisement by the PITR
Section 7:
- Section 7 should probably be the security considerations section.
Section 8.2 and 8.3:
- LISP supports IPv6 transitions and VPN not because of the
architectural characteristics that are unique to LISP, but because of the
architectural characteristics that it shares with many other solutions. While
it may support IPv6 transitions and VPN, it may not do so as well as existing
solutions.
-
Ron
From: lisp [mailto:[email protected]] On Behalf Of Luigi Iannone
Sent: Saturday, October 25, 2014 8:04 AM
To: LISP mailing list list
Cc: Damien Saucez
Subject: [lisp] WG Last Call on draft-lisp-introduction-07
All,
A lot of work has been done lately on draft-ietf-lisp-introduction-07 and the
authors requested a work group last call.
This email starts a WG last call, to end November 14th, 2014.
You will find the document here:
http://tools.ietf.org/html/draft-ietf-lisp-introduction-07
Please review this WG document. Let the working group know if you agree that
it is ready for handing to the AD, or if you see issues with it.
If you see issues, please be as specific as possible about the problems, and if
possible suggest text to resolve them.
Joel & Luigi
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
