Subject: [lisp] [Fwd: RtgDir review: draft-ietf-lisp-alt-03.txt]

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 02 Mar 2010 10:17:37 -0500

Below is a review we have received from teh routing Directorate.
This is a separate review from the one our routing advisor is preparing.
I am very pleased that we are getting a number of reviews.

Please copy John on your comments or questions.

Yours,
Joel M. Halpern

-------- Original Message --------
Subject: RtgDir review: draft-ietf-lisp-alt-03.txt
Date: Mon, 1 Mar 2010 10:26:05 +0200
From: John G.Scudder <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, 
<[email-masked]>

[resending with correct address for rtg-dir]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review. The purpose 
of the review is to provide assistance to the Routing ADs. For more 
information about the Routing Directorate, please see 
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-ietf-lisp-alt-03.txt (as posted to LISP mailing list on 
Feb 23)
Reviewer: John Scudder
Review Date: March 1, 2010
IETF LC End Date: Unknown
Intended Status: Experimental

Summary:

Since the status of the document is Experimental, I evaluate it as " I 
have some minor concerns about this document that I think should be 
resolved before publication."

If the status of the document were Proposed Standard, I would evaluate 
it as "I have significant concerns about this document and recommend 
that the Routing ADs discuss these issues further with the authors."

(See the next section for a little more discussion.)

Comments:

The intended status of the document is Experimental.  Many of the issues 
identified here can be seen as not being relevant to an Experimental 
document, which RFC 2026 says is simply "archival record of the work, 
subject only to editorial considerations".  They would be relevant to a 
standards track document.

The high-order bit of the document is simply to use a tunneled overlay 
network to route IP datagrams.  This is of course, straightforward in 
principle.  However, the document needs revision to improve readability, 
provide detail about the specific use envisioned, remove some tangential 
matter that muddies the waters, and disclose complicating factors.  Such 
issues are identified below.

Major Issues:

The document's goal is to "[describe] a method of building an 
Alternative Logical Topology" I'm not sure that I'd say it achieves this 
goal.  Some key aspects of building such a topology are how to 
interconnect the member routers and how to perform aggregation at the 
various levels; these are addressed in general terms but not in 
sufficient detail to tell someone how do it for the ALT.  Also missing 
is any information of how one might connect to the deployed ALT although 
this may be a non-goal, since it's beyond the scope of just "a method of 
building".  I would buy "outline an architecture for building" as a 
description of the document as it stands.  If the document actually 
wants to do what the abstract says, I think it needs more detail 
especially in sections 7-9, preferably with examples.

The document doesn't attempt to tackle questions of deployment at scale. 
  Some of the open technical issues are identified (e.g. in the security 
section) although none of the operational ones are discussed.  Examples 
of potential operational issues might be the manageability of a 
large-scale tunneled overlay network, the ability of operators to 
troubleshoot customer issues when there is no easy way to distinguish an 
"EID" from a conventional IP address, and how to handle sites that leak 
their "EID" prefix into the regular Internet routing, either 
accidentally or on purpose.

The Security section discusses a number of possible attacks.  Here's 
another one: "EID" prefix injection into the plain old Internet routing. 
  Such an attack would appear to be at increased likelihood of success 
compared to an identical attack against a normal IP prefix.  This is 
because per [LISP] only a highly aggregated "EID" prefix would be 
advertised into the plain old Internet, making a longer-prefix attack 
likely to succeed.  This is admittedly really a shortcoming in the BGP 
"security" model and would be addressed by any solution which addresses 
the underlying problem; still, the problem seems to be exacerbated by 
LISP.  Presumably such an attack wouldn't be effective to divert traffic 
from a LISP source, but it would work against non-LISP sources (i.e. the 
majority of the Internet).  This may be a case of "can't make an 
omelette without breaking eggs" but it's still worth noting.

The document emphasizes that the ALT is to be used only to forward ALT 
datagrams.  Since "ALT datagrams" are just IP packets as far as the ALT 
Routers are concerned, are technical means needed to enforce this 
assumption?  This would seem to deserve treatment in the main body of 
the document, or at least in the Security section.  As it is, it would 
appear easy to inject arbitrary packets into the ALT.

S5.3 claims "LISP+ALT ... reduces ... OPEX".  I don't think this claim 
is justified by evidence.  (I can see a stronger case for claiming it 
reduces vendor development costs.)  I understand that there is goodness 
from not having to train folks in the use of a new protocol.  On the 
other hand, much will depend on how the overlay network is constructed 
and maintained.  Until experience is gained in that, it's not knowable 
whether opex is high or low overall.  Furthermore, the statement begs 
the question, reduces opex compared to what?  For these reasons, I think 
it would be better to remove this claim.

ALT's claims to scalability rest on high levels of aggregation with no 
hole punching.  This has implications on the necessary business 
relationships between EID users and EID suppliers, and the types of 
suballocation that can and cannot be done.  Most importantly, it implies 
that EID users will be locked in to their EID supplier, of course unless 
they are willing to renumber into different EID space -- but freedom 
from renumbering is a goal of LISP.  This consequence probably should be 
spelled out in some fashion.  This might come naturally from a much more 
detailed description of specifics as I raise in other points, or it 
might need its own section.

Minor Issues:

S.1 The document cites RFC 2119 but barely uses the terminology.  It's 
limited to one MUST in S.3 and one more in S.4.  There are many places 
where 2119 type language would clarify things.  For example, look at the 
uses of "should".  A number could be turned into MUST or in some cases, 
SHOULD.  (Others really are the plain old English "should".)  Although 
one option would be to ditch the use of 2119 language altogether 
(including removing the citation) I'd prefer to see the document worked 
over to use it properly.  To take just one example, S6.1 ("Changes to 
ITR behavior with LISP+ALT") seems to cry out for some MUSTs where 
"should" is used.

S.2 notes that "an important design goal of LISP+ALT is to minimize the 
number of changes to existing hardware and/or software".  This begs the 
question of what the other design goals were.  It would be useful to 
know this, as a way of letting the reader evaluate how well LISP+ALT 
meets those goals.  Were there any explicit non-goals?

S.3 says that an EID is the address used in the first "LISP header" of a 
packet.  Does the LISP architecture refer to the header of the 
encapsulated packet as a "LISP header"?  If so I think that is 
unfortunate; it's really just an IP header (and that's how the host that 
emitted it thinks of it; isn't that the point?).  But, if so then I 
think there needs to be a discussion of this renaming of the IP header 
and just exactly what "LISP header" means.  OTOH, maybe this is just an 
editorial error, in which case it looks as though it should say "IP 
header".  (Based on the definition of "LISP header" in [LISP] I think 
it's just an editorial error.)  Also, this paragraph says "system" where 
I think it should say "host".

S.3, the definition of EID Prefix Reachability refers to "the ETR (or 
its proxy)".  The notion of an ETR's proxy isn't amplified on in the 
spec.  Either do so, or cite another document which does so ([LISP-IW]?).

Section 4.3 notes that "Data Probes ... should be considered 
experimental."  Isn't all of LISP experimental, by definition?  When 
seen in that light, this statement is quite odd.  I'm not really sure 
what your goal is with this phrasing so it's hard for me to suggest 
different wording, but something needs to change.  (This would also seem 
to be a good place for 2119 type language, e.g. "MUST be disabled by 
default".)  It might help clarity to restructure the doc making 
Map-Request the only lookup method documented in the main doc, and move 
all discussion of Data Probes to an appendix.

S5.1, second paragraph, "additional packets destined to the given EID 
prefix are routed directly to a viable ETR without use of the ALT, until 
either the entry's TTL has expired, or the ITR can otherwise find no 
reachable ETR."  Considering that the next sentence says that 
non-reachability of all the RLOCs in the mapping does not constitute 
"can otherwise find no reachable ETR" I wonder what WOULD be covered by 
this clause?

S5.2, third paragraph, provides an example of aggregation that is mostly 
holes.  Either the paragraph should be updated to get rid of the holes 
(replace /24 with /18) or the aggregation-across-holes should be 
explicitly addressed.

S5.3, it took me several reads to understand what point "[a]lso, since 
tunnel IP addresses are local in scope, no coordination is needed for 
their assignment" is getting at.  Maybe something like "... since any 
given tunnel in the ALT is only relevant to the pair of routers that 
connects over it, the only requirement of the IP addresses used to 
establish that tunnel is that the involved routers should be able to 
reach each other."  Or something like that.

Section 7.2 (SAFI for LISP+ALT) asks whether it would be prudent to use 
a different SAFI to syntactically distinguish ALT routes from Internet 
routes.  This seems like a good idea to me since it would help eliminate 
one hard-to-debug routing problem (and source of increased opex, see 
other comments).  However, if this is done it has the disadvantage of 
eliminating the possibility of using COTS routers for ALT routers.

S8.1 "First, since reachability of RLOCs is learned through the LISP 
ITR-ETR exchange, "flapping" (frequent BGP updates and withdrawals) is 
not likely, and mapping information cannot become "stale" due to slow 
propagation through the ALT BGP mesh."  I can't tell what this sentence 
is trying to say.

S8.1 The relationship of LISP+ALT to traffic engineering seems to be 
fairly tenuous; this section seems to primarily recapitulate elements of 
the LISP architecture (not ALT) that are related to traffic engineering. 
  I would suggest removing the section entirely, or if not then reducing 
it just to the first two sentences plus a statement that ALT as such 
does not relate to traffic engineering, perhaps with a reference to the 
relevant section of [LISP].
  The following comments apply only to the (I would argue) extraneous 
matter and as such, would be most easily addressed by removing it.
  This section glosses over the fact that although some traffic 
engineering capabilities are gained, others are lost, and that costs are 
transferred in some cases.  Depending on the scenario, some players in 
the traffic engineering equation win, others lose.  Notably, transit 
providers can be seen as losing.  For transit traffic, if all traffic 
flows toward well-aggregated prefixes, the ability of transit SPs to 
engineer those flows by making fine-grained adjustments to routing is 
hampered.  Elsewhere in the LISP document set it is suggested that this 
can be addressed by having the transit provider re-encapsulate the 
transit traffic.  While this may enable the transit provider to regain 
egress selection TE control, it comes at the cost of deploying new 
encapsulating and decapsulating routers at the transit provider border. 
  Further, current routing-based TE can provide a modicum of ingress 
selection control; no replacement is offered for this.  There are 
further changes in the "balance of power" between traffic sinks, 
transits, and traffic sources as well.  Thus, while I would agree that 
the TE capabilities provided by LISP are better in some ways, they may 
be seen as worse in others, and the "improved traffic engineering" 
claims of this section are incomplete without a discussion of the tradeoffs.

S8.2 and elsewhere mention that "It is again worth noting that the ALT 
carries only EID-prefixes, used to construct BGP paths to their owning 
ETRs; this set of information is considerably less volatile than the 
actual EID-to-RLOC mappings."  It's not clear to me why it should be 
much less volatile.  Presumably the mapping changes whenever an RLOC is 
(permanently) added or deleted.  Equally, one would assume that since 
each RLOC corresponds to an ETR, when an RLOC is added the ETR must be 
advertised into the ALT, and when an RLOC is deleted the ETR 
advertisement must be removed.  Thus the naive analysis is that the ALT 
routes should be at least equally volatile (but actually more so because 
the routing will reflect the dynamic state of the ETR connectivity). 
Perhaps Map Servers are supposed to help with this?  Or maybe the point 
is that aggregation should hide the volatility close to the source?  In 
any case, the statement as written doesn't seem to be quite right.

The various discussions of aggregation seem to be lacking in detail 
considering that aggregation is said to be key to this scheme.  In 
particular, there is no mention of whether and when to suppress 
more-specifics.  I suppose it may be assumed that you always do so? 
This needs to be made clear.  Diagrams would help.

S11.3 the citation for S-BGP (not sBGP) is wrong.

S13, References.  Surely [LISP] must be a normative reference? [LISP-MS] 
also seems to be.

Nits:

The final paragraph of S.2 summarizes most of the following sections 
other than S.7 and sections 10+.  Seemed odd to omit those.

The definition of RLOC should probably mention that "locator" is used 
interchangeably with "RLOC".  Or, the uses of "locator" could be 
replaced by "RLOC".

S.4, the first use of the acronym "DA" is not defined.  (Seems to have 
come from some c-n-p of paragraphs in the latest revision, since the 
term is defined later.)

In section 5, "A LISP+ALT router near the edge learns EID prefixes 
originated by authoritative ETRs".  You haven't defined "the edge" but 
shouldn't this be *at* the edge?  (If you really mean "near" then what 
is "the edge", and how near is near?)

S5.1 talks about Data Probes without mentioning that they're discouraged.

S5.2, first paragraph, "The ALT network is built in a tree-structured 
hierarchy".  S8 later says "The ALT BGP peering topology should be 
arranged in a tree-like fashion (with some meshiness)".  The latter 
makes more sense than the former for practical purposes, but anyway they 
need to be reconciled.

S6.1 -- I think you could s/explicitly//g and increase clarity.  If you 
want to be emphatic, IMO you'd be better off using 2119 terminology.

S9.1 "TCP-connected ETRs".  These are not defined.

The [Interworking] reference has expired.

In addition, the following minor changes.  This is against the version 
that was sent to [email-masked] on Feb 23:

jgs$ diff draft-ietf-lisp-alt-03.txt draft-ietf-lisp-alt-03-marked-up.txt
250c250
<    It is important to note that the ALT does not distibute actual EID-
---
>  It is important to note that the ALT does not distribute actual EID-
352c352
<       the ETR that "owns" and EID-prefix.  As a tunneled overlay, its
---
>     the ETR that "owns" an EID-prefix.  As a tunneled overlay, its
403c403
<       the ALT on behalf of those ETRs, and forwards Map-Reqeusts to
---
>     the ALT on behalf of those ETRs, and forwards Map-Requests to
407c407
<       Map-Reqeust from a non-ALT-connected ITR, decapsulates it, and
---
>     Map-Request from a non-ALT-connected ITR, decapsulates it, and
427c427
<       router (ITR or ETR).  Also the output of a EID-to-RLOC mapping
---
>     router (ITR or ETR).  Also the output of an EID-to-RLOC mapping
441c441
<       one or more of its locators are reachable.  That is, an EID-prefix
---
>     one or more of its locators is reachable.  That is, an EID-prefix
459c459
<     ALT Default Route:  A EID-prefix value of 0.0.0.0/0 (or 0::/0 for
---
>   ALT Default Route:  An EID-prefix value of 0.0.0.0/0 (or 0::/0 for
511c511
<    is documented in [LISP].  In particular, LISP+ALT provides two types
---
>  is documented in [LISP].  In particular, LISP+ALT provides two types of
522,523c522,523
<       data packet destined for a EID with no known RLOCs into the ALT as
<       a Data Probe.  This might be done minimize packet loss and to
---
>     data packet destined for an EID with no known RLOCs into the ALT as
>     a Data Probe.  This might be done to minimize packet loss and to
528c528
<       site.  Note that the Data Probe the inner Destination Address
---
>     site.  Note that the Data Probe's inner Destination Address
536c536
<    an RLOC, there may be situations (i.e. for experimentation with
---
>  an RLOC, there may be situations (e.g. for experimentation with
578c578
<        control over how its EID-prefixes are advertised in to the ALT,
---
>      control over how its EID-prefixes are advertised into the ALT,
687c687
<    ALT Routers.  The ALT BGPRoute Information Base (RIB) is comprised of
---
>  ALT Routers.  The ALT BGP Routing Information Base (RIB) is comprised of
694c694
<    An ITR use the ALT to learn the best path for forwarding an ALT
---
>  An ITR uses the ALT to learn the best path for forwarding an ALT
719c719
<    that an ALT Datagram sent in to the ALT can be forwarded to the ETR
---
>  that an ALT Datagram sent into the ALT can be forwarded to the ETR
741c741
<    When an ITR receives a packet originated by an end system withind its
---
>  When an ITR receives a packet originated by an end system within its
772c772
<    Multiple allocations may not be in power-of-2 blocks.  But when they
---
>  Multiple allocations may not be in power-of-2 blocks, but when they
793,794c793,794
<    sessions to all of the originators of components (more-specifics
<    prefixes) of that aggregate.  Not all of the components of need to be
---
>  sessions to all of the originators of components (more-specific
>  prefixes) of that aggregate.  Not all of the components need to be
813c813
<    An ALT Router MUST NOT genearte an aggregate that includes a non-
---
>  An ALT Router MUST NOT generate an aggregate that includes a non-
832c832
<    are maintained.
---
>  can be maintained.
1372c1372
<       Reqeusts and fill its mapping cache?  Further study is required to
---
>     Requests and fill its mapping cache?  Further study is required to