From jgs@juniper.net Mon Mar 1 00:26:38 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29113A88EB for ; Mon, 1 Mar 2010 00:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNLxjKTxDcvL for ; Mon, 1 Mar 2010 00:26:37 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id A2CE03A8877 for ; Mon, 1 Mar 2010 00:26:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKS4t6OwzGLD/XvIEfxKgALFUQGvUDNnOH@postini.com; Mon, 01 Mar 2010 00:26:37 PST Received: from jgs-sslvpn-nc.jnpr.net (172.24.234.21) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.393.1; Mon, 1 Mar 2010 00:26:11 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1077) From: John G.Scudder Date: Mon, 1 Mar 2010 10:26:05 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: To: X-Mailer: Apple Mail (2.1077) Cc: rtg-dir@ietf.org, draft-ietf-lisp-alt@tools.ietf.org, lisp-chairs@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-lisp-alt-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 08:26:39 -0000 [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 lisp@ietf.org 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 From russ@cisco.com Mon Mar 1 08:35:42 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E813528C43A for ; Mon, 1 Mar 2010 08:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1yjORI5kwyN for ; Mon, 1 Mar 2010 08:35:41 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DA31C28C2EC for ; Mon, 1 Mar 2010 08:35:36 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKdmi0tAZnwN/2dsb2JhbACbD3OicJdYhHsEgxeGWw X-IronPort-AV: E=Sophos;i="4.49,561,1262563200"; d="scan'208";a="490010024" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-6.cisco.com with ESMTP; 01 Mar 2010 16:35:37 +0000 Received: from [127.0.0.1] (rtp-russwh-8712.cisco.com [10.116.137.179]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o21GZaBF012871; Mon, 1 Mar 2010 16:35:36 GMT Message-ID: <4B8BECE7.80900@cisco.com> Date: Mon, 01 Mar 2010 11:35:51 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rtg-ads@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, tcmp-chairs@tools.ietf.org, draft-ietf-tcpm-tcp-auth-opt-10@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-tcpm-tcp-auth-opt-10.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 16:35:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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-tcpm-tcp-auth-opt-10.txt Reviewer: Russ White Review Date: 1 March 2010 IETF LC End Date: not known Intended Status: Standards Track Summary: No issues found. This document is ready for publication. Comments: This draft is very readable and well organized. No major or minor issues were found. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuL7OcACgkQER27sUhU9OSSqgCfReHJMvKzLGg0eg5EOHpn+KxT FWcAoJOjbxx7RwIS1Zg6jSyTFtXlLOtb =wlGK -----END PGP SIGNATURE----- From d3e3e3@gmail.com Tue Mar 2 12:40:22 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515E83A8547 for ; Tue, 2 Mar 2010 12:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2yhNSkd3SWx for ; Tue, 2 Mar 2010 12:40:21 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id BF1223A6920 for ; Tue, 2 Mar 2010 12:40:20 -0800 (PST) Received: by wwb31 with SMTP id 31so352664wwb.31 for ; Tue, 02 Mar 2010 12:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=XFo2oJ7cFZjVqmlq1x7BcxFsMCocW4SeqZxHeXZjeR0=; b=JlJoXFPgKJxO0t9FxjVCoHw7jsO88+LUwgyAhWLh0faOvtkQsac7SBgM4bM0Ot0rxb VHfBRHCBHnUnEzQTSplxlGjPTvAj/wscPmkNzMX0x4Nrcvi5UJYRiMMRipcRLSnHEa1r 9gFtawoAqRpxle+moFX+iEbX3OLjBXU3dCKRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PQk/G36U0Fp0DNZbZxSjK02nMst16tHrTRAxHXeEeH7kEk9xyfN1/UPFdWbpqDrkPI irNm9bNCzOIYe8qK4g0kDE9hp6Jfc8Sbwo2oNa2cLGxLPLoG5hiErwEAOoMu4hU4W/sE iELQeo4YcLvuowwumEj7yANaH+zYpjSpJcgDQ= MIME-Version: 1.0 Received: by 10.216.163.11 with SMTP id z11mr1132323wek.24.1267562418561; Tue, 02 Mar 2010 12:40:18 -0800 (PST) In-Reply-To: <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> Date: Tue, 2 Mar 2010 15:40:18 -0500 Message-ID: <1028365c1003021240i60b2bb09p9cb594c489741627@mail.gmail.com> From: Donald Eastlake To: Acee Lindem Content-Type: multipart/mixed; boundary=00163641780bb0634c0480d75f16 X-Mailman-Approved-At: Tue, 02 Mar 2010 13:10:06 -0800 Cc: "rtg-dir@ietf.org" , "dratf-ietf-trill-rbridge-protocol@tools.ietf.org" , Ralph Droms , "trill-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 20:40:22 -0000 --00163641780bb0634c0480d75f16 Content-Type: text/plain; charset=ISO-8859-1 Hi Acee, On Wed, Feb 24, 2010 at 2:52 PM, Acee Lindem wrote: > Hi Donald, > See inline. > On Feb 18, 2010, at 12:07 AM, Donald Eastlake wrote: > >> Hi Acee, >> >> Thanks for your detailed comments. >>... >>> Minor Issues: >> >>> The RBridge configuration in section 5 should include the default >>> values and ranges of values. >> >> That can be done for the configuration items added by TRILL. But where >> whole blocks of parameters are incorporated by reference (such as all >> 802.1Q-2005 port VLAN and priority parameters), I don't see a need to >> list in the TRILL specification all the default values and ranges >> copied from the referenced document. > I agree (these reference documents could simply be cited, if they > are not already). The changes to Section 5 are moderately extensive. A candidate Section 5 draft is attached. >>... > Thanks, > Acee Thanks, Donald --00163641780bb0634c0480d75f16 Content-Type: text/plain; charset=US-ASCII; name="Section5.txt" Content-Disposition: attachment; filename="Section5.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g6b5xi970 SU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS QnJpZGdlIFByb3RvY29sCgoKNS4gUkJyaWRnZSBQYXJhbWV0ZXJzCgogICBUaGlzIHNlY3Rpb24g bGlzdHMgcGFyYW1ldGVycyBmb3IgUkJyaWRnZXMuIEl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlCiAg IFRSSUxMIE1JQiB3aWxsIGluY2x1ZGUgbWFueSBvZiB0aGUgaXRlbXMgbGlzdGVkIGluIHRoaXMg c2VjdGlvbiBwbHVzCiAgIGFkZGl0aW9uYWwgUmJyaWRnZSBzdGF0dXMgYW5kIGRhdGEgaW5jbHVk aW5nIHRyYWZmaWMgYW5kIGVycm9yCiAgIGNvdW50cy4KCiAgIFRoZSBkZWZhdWx0IHZhbHVlIGFu ZCByYW5nZSBhcmUgZ2l2ZW4gZm9yIHBhcmFtZXRlcnMgYWRkZWQgYnkgVFJJTEwuCiAgIFdoZXJl IGEgcGFyYW1ldGVyIGlzIGRlZmluZWQgYXMgYSAxNi1iaXQgdW5zaWduZWQgaW50ZWdlciBhbmQg YW4KICAgZXhwbGljaXQgbWF4aW11bSBpcyBub3QgZ2l2ZW4sIHRoYXQgbWF4aW11bSBpcyAyKiox Ni0xLiAgRm9yCiAgIHBhcmFtZXRlcnMgaW1wb3J0ZWQgZnJvbSBbODAyLjFRLTIwMDVdLCBbODAy LjFEXSwgb3IgSVMtSVMgW0lTTzEwNTg5XQogICBbUkZDMTE5NV0sIHNlZSB0aG9zZSBzdGFuZGFy ZHMgZm9yIGRlZmF1bHQgYW5kIHJhbmdlIGlmIG5vdCBnaXZlbgogICBoZXJlLgoKCgo1LjEgUGVy IFJCcmlkZ2UKCiAgIFRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyBvY2N1ciBwZXIgUkJyaWRnZToK CiAgICAgIG8gIE51bWJlciBvZiBuaWNrbmFtZXMsIHdoaWNoIGRlZmF1bHRzIHRvIDEgYW5kIG1h eSBiZSBjb25maWd1cmVkCiAgICAgICAgIGluIHRoZSByYW5nZSBvZiAxIHRvIDI1Ni4KCiAgICAg IG8gIFRoZSBkZXNpcmVkIG51bWJlciBvZiBkaXN0cmlidXRpb24gdHJlZXMgdG8gYmUgY2FsY3Vs YXRlZCBieQogICAgICAgICBldmVyeSBSQnJpZGdlIGluIHRoZSBjYW1wdXMgYW5kIGEgZGVzaXJl ZCBudW1iZXIgb2YKICAgICAgICAgZGlzdHJpYnV0aW9uIHRyZWVzIGZvciB0aGUgYWR2ZXJ0aXNp bmcgUkJyaWRnZSB0byB1c2UsIGJvdGggb2YKICAgICAgICAgd2hpY2ggYXJlIHVuc2lnbmVkIDE2 LWJpdCBpbnRlZ2VycyB0aGF0IGRlZmF1bHQgdG8gMSAoc2VlCiAgICAgICAgIFNlY3Rpb24gNC41 KS4KCiAgICAgIG8gIFRoZSBtYXhpbXVtIG51bWJlciBvZiBkaXN0cmlidXRpb24gdHJlZXMgdGhl IFJCcmlkZ2UgY2FuCiAgICAgICAgIGNvbXB1dGUuIFRoaXMgaXMgYSAxNiBiaXQgdW5zaWduZWQg aW50ZWdlciB3aGljaCBpcwogICAgICAgICBpbXBsZW1lbnRhdGlvbiBhbmQgZW52aXJvbm1lbnQg ZGVwZW5kZW50IGFuZCBub3Qgc3ViamVjdCB0bwogICAgICAgICBtYW5hZ2VtZW50IGNvbmZpZ3Vy YXRpb24uCgogICAgICBvICBUd28gbGlzdHMgb2Ygbmlja25hbWVzLCBvbmUgZGVzaWduYXRpbmcg dGhlIGRpc3RyaWJ1dGlvbiB0cmVlcwogICAgICAgICB0byBiZSBjb21wdXRlZCBhbmQgb25lIGRl c2lnbmF0aW5nIGRpc3RyaWJ1dGlvbiB0cmVlcyB0byBiZQogICAgICAgICB1c2VkIGFzIGRpc2N1 c3NlZCBpbiBTZWN0aW9uIDQuNS4gQnkgZGVmYXVsdCwgdGhlc2UgbGlzdHMgYXJlCiAgICAgICAg IGVtcHR5LgoKICAgICAgbyAgVGhlIHBhcmFtZXRlcnMgQWdlaW5nIFRpbWVyIGFuZCBGb3J3YXJk IERlbGF5IHdpdGggdGhlIGRlZmF1bHQKICAgICAgICAgYW5kIHJhbmdlIHNwZWNpZmllZCBpbiBb ODAyLjFRLTIwMDVdLgoKICAgICAgbyAgVHdvIHVuc2lnbmVkIG9jdGV0cyB0aGF0IGFyZSwgcmVz cGVjdGl2ZWx5LCB0aGUgY29uZmlkZW5jZSBpbiB7CiAgICAgICAgIE1BQywgVkxBTiwgbG9jYWwg cG9ydCB9IHRyaXBsZXMgbGVhcm5lZCBmcm9tIGxvY2FsbHkgcmVjZWl2ZWQKICAgICAgICAgbmF0 aXZlIGZyYW1lcyBhbmQgdGhlIGNvbmZpZGVuY2UgaW4geyBNQUMsIFZMQU4sIHJlbW90ZSBSQnJp ZGdlCiAgICAgICAgIH0gdHJpcGxlcyBsZWFybmVkIGZyb20gZGVjYXBzdWxhdGluZyBmcmFtZXMu IFRoZXNlIGVhY2ggZGVmYXVsdAogICAgICAgICB0byAweDIwIGFuZCBtYXkgZWFjaCBiZSBjb25m aWd1cmVkIHRvIHZhbHVlcyBmcm9tIDB4MDAgdG8gMHhGRS4KCiAgICAgIG8gIFRoZSBkZXNpcmVk IG1pbmltdW0gYWNjZXB0YWJsZSBpbnRlci1SQnJpZGdlIGxpbmsgTVRVIGZvciB0aGUKICAgICAg ICAgY2FtcHVzLCB0aGF0IGlzLCBvcmlnaW5hdGluZ0xTUEJ1ZmZlclNpemUuIFRoaXMgaXMgYSAx NiBiaXQKCgpSLiBQZXJsbWFuLCBldCBhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSA3OF0KDApJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJCcmlkZ2UgUHJvdG9jb2wKCgogICAgICAgICB1bnNp Z25lZCBpbnRlZ2VyIG51bWJlciBvZiBvY3RldHMgdGhhdCBkZWZhdWx0cyB0byAxNDcwIGJ5dGVz LAogICAgICAgICB3aGljaCBpcyB0aGUgbWluaW11bSB2YWxpZCB2YWx1ZS4gQW55IGxvd2VyIHZh bHVlIGJlaW5nCiAgICAgICAgIGFkdmVydGlzZWQgYnkgYW4gUkJyaWRnZSBpcyBpZ25vcmVkLgoK ICAgICAgbyAgVGhlIG51bWJlciBvZiBmYWlsZWQgTVRVLXByb2JlcyBiZWZvcmUgdGhlIFJCcmlk Z2UgY29uY2x1ZGVzCiAgICAgICAgIHRoYXQgYSBwYXJ0aWN1bGFyIE1UVSBpcyBub3Qgc3VwcG9y dGVkLCB3aGljaCBkZWZhdWx0cyB0byAzIGFuZAogICAgICAgICBtYXkgYmUgY29uZmlndXJlZCBi ZXR3ZWVuIDEgYW5kIDI1NS4KCiAgIFN0YXRpYyBlbmQgc3RhdGlvbiBhZGRyZXNzIGluZm9ybWF0 aW9uIGFuZCBjb25maWRlbmNlIGluIHN1Y2ggZW5kCiAgIHN0YXRpb24gaW5mb3JtYXRpb24gc3Rh dGljYWxseSBjb25maWd1cmVkIGNhbiBhbHNvIGJlIGNvbmZpZ3VyZWQgd2l0aAogICBhIGRlZmF1 bHQgY29uZmlkZW5jZSBvZiAweEZGIGFuZCByYW5nZSBvZiAweDAwIHRvIDB4RkYuIEJ5IGRlZmF1 bHQsCiAgIHRoZXJlIGlzIG5vIHN1Y2ggc3RhdGljIGFkZHJlc3MgaW5mb3JtYXRpb24uIFRoZSBx dWFudGl0eSBvZiBzdWNoCiAgIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIGNvbmZpZ3VyZWQgaXMg aW1wbGVtZW50YXRpb24gZGVwZW5kZW50LgoKCgo1LjIgUGVyIE5pY2tuYW1lIFBlciBSQnJpZGdl CgogICBUaGUgZm9sbG93aW5nIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gcGVyIG5pY2tuYW1l IGF0IGVhY2ggUkJyaWRnZToKCiAgICAgIG8gIFByaW9yaXR5IHRvIGhvbGQgdGhlIG5pY2tuYW1l LCB3aGljaCBkZWZhdWx0cyB0byAweDQwIGlmIG5vCiAgICAgICAgIHNwZWNpZmljIHZhbHVlIGhh cyBiZWVuIGNvbmZpZ3VyZWQgb3IgMHhDMCBpZiBpdCBpcyBjb25maWd1cmVkCiAgICAgICAgIChz ZWUgU2VjdGlvbiAzLjcuMykuCgogICAgICBvICBOaWNrbmFtZSBwcmlvcml0eSB0byBiZSBzZWxl Y3RlZCBhcyBhIGRpc3RyaWJ1dGlvbiB0cmVlIHJvb3QsIGEKICAgICAgICAgMTYtYml0IHVuc2ln bmVkIGludGVnZXIgdGhhdCBkZWZhdWx0cyB0byAweDgwMDAuCgogICAgICBvICBOaWNrbmFtZSB2 YWx1ZSwgYW4gdW5zaWduZWQgMTYtYml0IHF1YW50aXR5IHdoaWNoIGRlZmF1bHRzIHRvCiAgICAg ICAgIHRoZSBjb25maWd1cmVkIHZhbHVlIGlmIGNvbmZpZ3VyZWQsIGVsc2UgdG8gdGhlIGxhc3Qg dmFsdWUgaGVsZAogICAgICAgICBpZiB0aGUgUkJyaWRnZSBjb21pbmcgdXAgYWZ0ZXIgYSByZS1i b290IGFuZCB0aGF0IHZhbHVlIGlzCiAgICAgICAgIHJlbWVtYmVyZWQsIGVsc2UgdG8gYSByYW5k b20gdmFsdWU7IGhvd2V2ZXIsIGluIGFsbCBjYXNlcyB0aGUKICAgICAgICAgcmVzZXJ2ZWQgdmFs dWVzIDB4MDAwMCBhbmQgMHhGRkMwIHRocm91Z2ggMHhGRkZGIGFyZSBleGNsdWRlZAogICAgICAg ICAoc2VlIFNlY3Rpb24gMy43LjMpLgoKCgo1LjMgUGVyIFBvcnQgUGVyIFJCcmlkZ2UKCiAgIEFu IFJCcmlkZ2UgaGFzIHRoZSBmb2xsb3dpbmcgcGVyIHBvcnQgY29uZmlndXJhdGlvbiBwYXJhbWV0 ZXJzOgoKICAgICAgbyAgVGhlIHNhbWUgcGFyYW1ldGVycyBhcyBhbiBbODAyLjFRLTIwMDVdIHBv cnQgaW4gdGVybXMgb2YgQy1WTEFOCiAgICAgICAgIElEcy4gIEluIGFkZGl0aW9uLCBhbiBBbm5v dW5jaW5nIFZMQU5zIHNldCB0aGF0IGRlZmF1bHRzIHRvIHRoZQogICAgICAgICBlbmFibGVkIFZM QU5zIG9uIHRoZSBwb3J0IChzZWUgU2VjdGlvbiA0LjQuMykgYW5kIHJhbmdlcyBmcm9tCiAgICAg ICAgIHRoZSBudWxsIHNldCB0byB0aGUgc2V0IG9mIGFsbCBsZWdhbCBWTEFOIElEcy4KCiAgICAg IG8gIFRoZSBzYW1lIHBhcmFtZXRlcnMgYXMgYW4gWzgwMi4xUS0yMDA1XSBwb3J0IGluIHRlcm1z IG9mIGZyYW1lCiAgICAgICAgIHByaW9yaXR5IGNvZGUgcG9pbnQgbWFwcGluZyAoc2VlIFs4MDIu MVEtMjAwNV0pLgoKICAgICAgbyAgVGhlIGluaGliaXRpb24gdGltZSBmb3IgdGhlIHBvcnQgd2hl biBpdCBvYnNlcnZlZCBhIGNoYW5nZSBpbgogICAgICAgICB0aGUgcm9vdCBicmlkZ2Ugb2YgYW4g YXR0YWNoZWQgYnJpZGdlZCBMQU4uIFRoaXMgaXMgaW4gdW5pdHMgb2YKCgpSLiBQZXJsbWFuLCBl dCBhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3 OV0KDApJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFJCcmlkZ2UgUHJvdG9jb2wKCgogICAgICAgICBzZWNvbmRzLCBkZWZhdWx0cyB0byAzMCwg YW5kIGNhbiBiZSBjb25maWd1cmVkIHRvIGFueSB2YWx1ZQogICAgICAgICBmcm9tIDAgdG8gMzAu CgogICAgICBvICBUaGUgZGVzaXJlZCBkZXNpZ25hdGVkIFZMQU4gdGhhdCB0aGUgUkJyaWRnZSB3 aWxsIGFkdmVydGlzZSBpbgogICAgICAgICBpdHMgVFJJTEwgSGVsbG9zIGlmIGl0IGlzIERSQiBm b3IgdGhlIGxpbmsgdmlhIHRoYXQgcG9ydC4gVGhpcwogICAgICAgICBkZWZhdWx0cyB0byB0aGUg bG93ZXN0IFZMQU4gSUQgZW5hYmxlZCBvbiB0aGUgcG9ydCBhbmQgbWF5IGJlCiAgICAgICAgIGNv bmZpZ3VyZWQgdG8gYW55IHZhbGlkIFZMQU4gSUQgdGhhdCBpcyBlbmFibGVkIG9uIHRoZSBwb3J0 CiAgICAgICAgICgweDAwMSB0aHJvdWdoIDB4RkZFKS4KCiAgICAgIG8gIEZvdXIgcGVyLXBvcnQg Y29uZmlndXJhdGlvbiBiaXRzOiBkaXNhYmxlIHBvcnQgKGRlZmF1bHQgMCA9PQogICAgICAgICBl bmFibGVkKSwgZGlzYWJsZSBlbmQgc3RhdGlvbiBzZXJ2aWNlICh0cnVuaywgZGVmYXVsdCAwID09 CiAgICAgICAgIGVuYWJsZWQpLCBhY2Nlc3MgcG9ydCAoZGVmYXVsdCAwID09IG5vdCByZXN0cmlj dGVkIHRvIGJlaW5nIGFuCiAgICAgICAgIGFjY2VzcyBwb3J0KSwgYW5kIHVzZSBQMlAgSGVsbG9z IChkZWZhdWx0IDAgPT0gdXNlIFRSSUxMCiAgICAgICAgIEhlbGxvcykuIChTZWUgU2VjdGlvbiA0 LjkuMS4pCgogICAgICBvICBPbmUgYml0IHBlciBwb3J0IHN1Y2ggdGhhdCwgaWYgdGhlIGJpdCBp cyBzZXQsIGl0IGRpc2FibGVzCiAgICAgICAgIGxlYXJuaW5nIHsgTUFDIGFkZHJlc3MsIFZMQU4s IHBvcnQgfSB0cmlwbGVzIGZyb20gbG9jYWxseQogICAgICAgICByZWNlaXZlZCBuYXRpdmUgZnJh bWVzIG9uIHRoZSBwb3J0LiBEZWZhdWx0IHZhbHVlIGlzIDAgPT0KICAgICAgICAgbGVhcm5pbmcg ZW5hYmxlZC4KCiAgICAgIG8gIFRoZSBwcmlvcml0eSBvZiB0aGUgUkJyaWRnZSB0byBiZSBEUkIg YW5kIGl0cyBIb2xkaW5nIFRpbWUgdmlhCiAgICAgICAgIHRoYXQgcG9ydCB3aXRoIGRlZmF1bHRz IGFuZCByYW5nZSBhcyBzcGVjaWZpZWQgaW4gSVMtSVMKICAgICAgICAgW0lTTzEwNTg5XSBbUkZD MTE5NV0uCgogICAgICBvICBBIGJpdCB3aGljaCwgd2hlbiBzZXQsIGVuYWJsZXMgdGhlIHJlY2Vp cHQgb2YgVFJJTEwtCiAgICAgICAgIGVuY2Fwc3VsYXRlZCBmcmFtZXMgZnJvbSBhbiBPdXRlci5N YWNTQSB3aXRoIHdoaWNoIHRoZSBSQnJpZGdlcwogICAgICAgICBkb2VzIG5vdCBoYXZlIGFuIElT LUlTIGFkamFjZW5jeS4gRGVmYXVsdCB2YWx1ZSBpcyAwID09CiAgICAgICAgIGRpc2FibGVkLgoK ICAgICAgbyAgQ29uZmlndXJhdGlvbiBmb3IgdGhlIG9wdGlvbmFsIHNlbmQtQlBEVXMgc29sdXRp b24gdG8gdGhlCiAgICAgICAgIHdpcmluZyBjbG9zZXQgdG9wb2xvZ3kgcHJvYmxlbSBhcyBkZXNj cmliZWQgaW4gU2VjdGlvbiBBLjMuMykuCiAgICAgICAgIERlZmF1bHQgQnJpZGdlIEFkZHJlc3Mg aXMgdGhlIFN5c3RlbSBJRCBvZiB0aGUgUkJyaWRnZSB3aXRoCiAgICAgICAgIGxvd2VzdCBTeXN0 ZW0gSUQuIElmIFJCMSBhbmQgUkIyIGFyZSBwYXJ0IG9mIGEgd2lyaW5nIGNsb3NldAogICAgICAg ICB0b3BvbG9neSwgYm90aCBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgdG8ga25vdyBhYm91dCB0aGlz LCBhbmQKICAgICAgICAga25vdyB0aGUgSUQgdGhhdCBzaG91bGQgYmUgdXNlZCBpbiB0aGUgc3Bh bm5pbmcgdHJlZSBwcm90b2NvbAogICAgICAgICBvbiB0aGUgc3BlY2lmaWVkIHBvcnQuCgoKCjUu NCBQZXIgVkxBTiBQZXIgUkJyaWRnZQoKICAgQW4gUkJyaWRnZSBoYXMgdGhlIGZvbGxvd2luZyBw ZXIgVkxBTiBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnM6CgogICAgICBvICBQZXIgVkxBTiBFU0FE SSBwcm90b2NvbCBwYXJ0aWNpcGF0aW9uIGZsYWcsIDctYml0IHByaW9yaXR5LCBhbmQKICAgICAg ICAgSG9sZGluZyBUaW1lLiBEZWZhdWx0IHBhcnRpY2lwYXRpb24gZmxhZyBpcyAwID09IG5vdAog ICAgICAgICBwYXJ0aWNpcGF0aW5nLiBEZWZhdWx0IGFuZCByYW5nZSBvZiBwcmlvcml0eSBhbmQg SG9sZGluZyBUaW1lCiAgICAgICAgIGFzIHNwZWNpZmllZCBpbiBJUy1JUyBbSVNPMTA1ODldIFtS RkMxMTk1XS4KCiAgICAgIG8gIE9uZSBiaXQgcGVyIFZMQU4gdGhhdCwgaWYgc2V0LCBkaXNhYmxl cyBsZWFybmluZyB7IE1BQyBhZGRyZXNzLAogICAgICAgICBWTEFOLCByZW1vdGUgUkJyaWRnZSB9 IHRyaXBsZXMgZnJvbSBmcmFtZXMgZGVjYXBzdWxhdGVkIGluIHRoZQoKClIuIFBlcmxtYW4sIGV0 IGFsICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDgw XQoMCklOVEVSTkVULURSQUZUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUkJyaWRnZSBQcm90b2NvbAoKCiAgICAgICAgIFZMQU4uIERlZmF1bHRzIHRvIDAgPT0gbGVh cm5pbmcgZW5hYmxlZC4KCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKUi4gUGVybG1hbiwgZXQgYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgODFdCg== --00163641780bb0634c0480d75f16-- From acee.lindem@ericsson.com Tue Mar 2 13:37:57 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3380528C226 for ; Tue, 2 Mar 2010 13:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaG2yduaWz3h for ; Tue, 2 Mar 2010 13:37:55 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 75DDD28C1F6 for ; Tue, 2 Mar 2010 13:37:55 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id o22LVn3O006541; Tue, 2 Mar 2010 15:39:49 -0600 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.204]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 2 Mar 2010 16:35:54 -0500 From: Acee Lindem To: Donald Eastlake Date: Tue, 2 Mar 2010 16:35:52 -0500 Thread-Topic: draft-ietf-trill-rbridge-protocol-15.txt Thread-Index: Acq6UFYe39AxyiZMRnaWMDMgggtFXw== Message-ID: <62ABF5D4-238F-4227-8A34-BC677521E21C@ericsson.com> References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> <1028365c1002252213sda034c6wb21a1dd3a1bfa5b5@mail.gmail.com> In-Reply-To: <1028365c1002252213sda034c6wb21a1dd3a1bfa5b5@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "dratf-ietf-trill-rbridge-protocol@tools.ietf.org" , Ralph Droms , "trill-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:37:57 -0000 Hi Donald,=20 Ok - I think you've addressed my issues. I did reread section 4.5 and I thi= nk I better understand the multi-destination frame forwarding. Rather than = defining a reference protocol state, as is done in RFC 4601, this document = defines the requirements and rules for forwarding frames from a given RBrid= ge on a chosen distribution tree (both of which are carried in the TRILL he= ader).=20 Thanks, Acee=20 On Feb 26, 2010, at 1:13 AM, Donald Eastlake wrote: > Hi Acee, >=20 > On Wed, Feb 24, 2010 at 2:52 PM, Acee Lindem w= rote: >> Hi Donald, >> See inline. >>=20 >> On Feb 18, 2010, at 12:07 AM, Donald Eastlake wrote: >>=20 >>> Hi Acee, >>>=20 >>> Thanks for your detailed comments. >>>=20 >>> On Tue, Feb 16, 2010 at 7:50 PM, Acee Lindem = wrote: >>>> ... >>>=20 >>>> I think this is a very complex protocol when you consider all the >>>> pieces and the interaction with IEEE 802.1 bridging. Hence, I think >>>> interoperable implementations are necessary for document advancement. >>>> Without them, I would think the intended status should be >>>> Experimental. >>>=20 >>> ... >>>=20 >>> I am not claiming the specification is perfect. But I believe it >>> clearly fits the criterion for Proposed Standard from RFC 2026: >>>=20 >>> A Proposed Standard specification is generally stable, has resolved >>> known design choices, is believed to be well-understood, has received >>> significant community review, and appears to enjoy enough community >>> interest to be considered valuable. However, further experience >>> might result in a change or even retraction of the specification >>> before it advances. >>>=20 >>> ... >=20 >> The ADs informed me that there is no requirement in the INT area for >> interoperable implementations or protocol experience. Hence, I guess >> it is a judgement call. If not two implementations, is there one >> righteous implementation that interoperates with itself? >=20 > There is an open source implementation for Solaris. >=20 > (By the way, according to UNH IOL, there are nine companies talking > with them about interoperability testing. And, although there are no > hardware TRILL products publicly announced, I was at NANOG 48 earlier > this week and am at the Ethernet Summit right now. At both there are > switch company booth personnel who seem quite happy to boast verbally > about how strongly their companies support TRILL and how they are > working on implementations.) >=20 >>> It is a Local Area Networking protocol based on a well understood >>> and deployed routing protocol, level 1 IS-IS. >=20 >> Well, not exactly. It is ISIS but the hello protocol is modified, it >> is being used for multicast distribution tree with new rules for tie >> breaking, and the application supported by the L2 topology >> information is brand new. >=20 > It is my impression that the IESG came to a general conclusion that > the application of any extra implementation/interoperability > requirement to the TRILL base protocol specification for Proposed > Standard would be at the discretion of the Internet Area Directors for > two reasons: > Such additional requirements are best applied to protocols or > protocol changes that would be expected to have pervasive effects on > the Internet, such as changes to TCP or BGP, not a local area > networking protocol. (I'm also adding an explict statement that it is > not a goal of TRILL to scale beyond the size of exisitng bridged LANs.) > There was no hint that such a requirement would be imposed in the > TRILL Charter or history so this would be an unexpected last-minute > requirement. >=20 >>>> There is a lengthy discussion on determining the inter-RBridge MTU >>>> for the purposes of TRILL control packets. However, what happens >>>> if an end-station sends a max-MTU packet and the 40 bytes of >>>> ethernet outer header and TRILL header cause the packet to be too >>>> large to be transported between RBridges? >>>=20 >>> Obviously, when a frame exceeds MTU on an Ethernet link, it is >>> generally discarded. (There did not appear to be any interest in the >>> TRILL WG in adding a link fragmentation protocol for such cases.) >>>=20 >>> The consensus of the TRILL WG is that this is not a problem as modern >>> switches have adequate headroom for headers and encapsulation and the >>> like. However, to assure safe operation of the TRILL Protocol in case >>> of limited MTU and to be able to take advantage of a high campus wide >>> inter-Rbridge link MTU, the TRILL MTU feature was added. >>>=20 >>> ... [The draft] >>> is careful, both in the Section heading and in the text, to say that >>> the TRILL MTU feature is for "Inter-RBridge Links". It also includes >>> the following paragraph (where "Sz" has already been defined as the >>> campus wide minimum inter-Rbridge link MTU): >>>=20 >>> Sz has no direct effect on end-stations and is not directly related >>> to any end-station to end-station "path MTU". Methods of using Sz or >>> any link MTU information gathered by TRILL IS-IS in the traffic >>> engineering of routes or the determination of any path MTU is beyond >>> the scope of this document. >>>=20 >>> A sentence could be add to the above paragraph such as "Native frames >>> that, after TRILL encapsulation, exceed the MTU of a link on which >>> they would be sent will generally be discarded." >=20 >> Maybe this should be stated explicitly. It seems to me that any >> draft that adds an additional level of encapsulation (outer ethernet >> + TRILL header) should have some discussion. >=20 > I will add the above sentence in draft version -16 to make this explicit. >=20 >>> By the way, I'm not sure where you get "40 bytes" for TRILL >>> encapsulation. It adds either 20 bytes or 24 bytes, depending on >>> whether an outer VLAN tag is sent on the wire (unless there are >>> options included in the TRILL Header): 12 for the outer destination >>> and source MAC addresses, possibly 4 for the outer VLAN tag, and 8 for >>> the TRILL header. In a fully RBridged point-to-point network there >>> would be no reason to include such an outer VLAN tag on TRILL data or >>> control frames sent between RBridges, so only 20 bytes would normally >>> be added. >>>=20 >>>> In a TRILL domain with multiple distribution trees, how does an >>>> ingress RBridge determine which distribution tree to use? I read >>>> section 4.5 several times and it is not clear to me how the >>>> ingress RBridge selects a distribution tree (other than everyone >>>> using the highest priority). Also, nickname terminology is >>>> confusing. Is the nickname1 tree the distribution tree rooted at >>>> RBridge 1 or is the nickname space for the distribution trees >>>> separate? >>>=20 >>> On tree selection: Other than the TRILL requirement that the ingress >>> RBridge announce the set of distribution trees that it might use, what >>> does it matter? The RBridge campus will operate "correctly" regardless >>> of what tree(s) are used by the ingress as long as it puts all the >>> frames that are part of the same order-dependent flow on the same >>> tree. In the absence of other considerations, it is probably best to >>> use the tree whose root RBridge is least cost from the ingress >>> RBridge. But, other than that, such questions as which sub-set of >>> distribution trees to use if you are multipathing multi-destination >>> frames seems like an excellent area for implementer creativity and >>> beyond the scope of this document. >=20 >> I may have missed exactly how it works. So, at the ingress, the >> frame is unicast to the root of the distribution tree selected by >> the ingress. The root of the distribution tree will then >> re-encapsulate it and send it on the distribution tree as a >> multicast. Correct? If so, then I agree with your statement. >=20 > No. That's not how it works. With a bidirectional tree, an > encapsulated packet can be injected anywhere, and travels from that > point. So the ingress encapsulates it, and it just travels from > there. The packet is not first unicast to the root and then > re-encapsulated. The reasons it is good to use a tree whose root is > least cost from the ingress RBridge are discussed in the first > paragraph of Section 4.5. >=20 > By the way, it turns out that in Section 4.6.1.2 of the current -15 > draft it does explicitly state that, by default, an RBridge using one > distribution tree chooses the one whose root is least cost from that > RBridge. (While not pseudo code, section 4.6 is the most detailed and > painstaking description in the draft of how to handle every type of > frame it is possible for an RBridge to receive.) I will also add this > to Section 4.5 where you were, quite reasonably, looking for it. >=20 >>> On nickname terminology: In early drafts, there was only one nickname >>> per RBridge, so distribution trees could equally well be considered to >>> be named by a nickname or uniquely determined by their root >>> RBridge. More recently the option of multiple nicknames per RBridge >>> was added and now distribution trees are uniquely labeled only by >>> their nickname. Nicknames are also permitted for pseudo-nodes. There >>> is only one nickname allocation space. Every nickname in use in a >>> campus designates either an RBridge or a pseudo-node and one or more >>> nicknames also each designate a distribution tree. >>>=20 >>> With this explanation, do you think that the draft text still needs >>> clarification and if so do you have any suggestions? >=20 >> Maybe section 3.7 could explicitly state that the distribution tree >> nicknames and the RBridge nicknames are independent of one >> another. Or if they are not, precisely explain the correlation. >=20 > OK, how about adding the following at the end of 3.7.3: >=20 > Every nickname in use in a campus identifies an RBridge (or > pseudonode) and every nickname designates a distribution tree > rooted at the RBridge (or pseudonode) it identifies. However, only > a limited number of these potential distribution trees are actually > computed by all the RBridge in a campus and they all compute the > same set of distribution trees, as discussed in Section 4.5. >=20 >>>> The document should explain the philosophy and usage of confidence >>>> level with respect to the {port, VLAN, MAC address} tuples. This >>>> discussion should also tie in the confidence configuration in >>>> section 5.1. >>>=20 >>> Well, how about something like the following new text: >>>=20 >>> The confidence level mechanism allows an RBridge campus manager to >>> cause certain address learning sources to prevail over others. In a >>> default configuration, without the optional ESADI protocol, >>> addresses are only learned from observing local native frames and >>> the decapsulation of received TRILL data frames. Both of these >>> sources default to confidence level 0x20 so, since learning at an >>> equal or high confidence overrides previous learning, the learning >>> in such a default case mimics default 802.1 bridge learning. >>>=20 >>> While RBridge campus management policies are beyond the scope of >>> this document, here are some example types of policies that can be >>> implemented with the confidence mechanism and the rational for >>> each: >>>=20 >>> o Locally received native frames might be considered more reliable >>> than decapsulated frames received from remote parts of the >>> campus. To stop MAC addresses learned from such local frames >>> from being usurped by remotely received forged frames, the >>> confidence in locally learned addresses could be increased or >>> that in addresses learned from remotely sourced decapsulated >>> frames decreased. >>>=20 >>> o MAC address information learned through a cryptographically >>> authenticated Layer 2 registration protocol, such as 802.1X with >>> a cryptographically based EAP method, might be considered more >>> reliable than information learned through the mere observation >>> of data frames. When such authenticated learned address >>> information is transmitted via the ESADI protocol, the use of >>> authentication in the TRILL EASDI LSP frames could make >>> tampering with it in transit very difficult. As a result, it >>> might be reasonable to announce such authenticated information >>> via the ESADI protocol with a high confidence, so it would >>> override any alternative learning from data observation. >>>=20 >>> Manually configured address information is generally considered >>> static and so defaults to a confidence of 0xFF while no other >>> source of such information can be configured to a confidence any >>> higher than 0xFE. However, for other cases, such as where the >>> manual configuration is just a starting point which the Rbridge >>> campus manager wishes to be dynamically overrideable, the >>> confidence of such manually configured information may be >>> configured to a lower value. >=20 >> This would be good. In the last sentence, do you mean the MAC >> addresses are dynamically learned or changing the configuration of >> the confidence level? I suspect the former. >=20 > Yes. I will replace "the manual configuration is" with "the manually > configred MAC addresses are". >=20 > Thanks, > Donald >=20 >>>> ... >=20 >> Thanks, >> Acee >>=20 >> ... >>>=20 >>> Thanks, >>> Donald [document Editor] >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street >>> Milford, MA 01757 USA >>> d3e3e3@gmail.com From d3e3e3@gmail.com Tue Mar 2 13:50:14 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A5728C185 for ; Tue, 2 Mar 2010 13:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuV2swqHAfjI for ; Tue, 2 Mar 2010 13:50:13 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B40CB3A8CDC for ; Tue, 2 Mar 2010 13:50:12 -0800 (PST) Received: by wwb31 with SMTP id 31so389398wwb.31 for ; Tue, 02 Mar 2010 13:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CC7gq7Qdgr3jDoELyxYbTN3J5dsqTE68DlyeouxYphs=; b=VZOipYzfpDUvNC9a3D8e5MHwxzgwJOPTw58d3XQZnYisk45nefCsu3gptY3Yho2/ai d3D8tOUVc9hUspsqKK+h13j3mdANeFgLfYxDojihmwToQThWWUK1JohMPK38XZTx/+yE OisvXA8D2TSI3z3Z65thhQvSpcmhhRM30F/Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XGBz3BbcvanXWyp1Ntcf01+dhncIWWeOaXyYoexf5CphL4WMF4/XoYW6kISDPNmRs+ HKTB8CrkC3ATwD+ToQQ+IDZY4FqO8WLDHSdZPQ+8UCI7mz9EQw2DbXGxX5/U//5PmrGn f9yXfABgJmnyh73ljRmOotU2Vbw48fNnVhUCQ= MIME-Version: 1.0 Received: by 10.216.87.146 with SMTP id y18mr444299wee.127.1267566610175; Tue, 02 Mar 2010 13:50:10 -0800 (PST) In-Reply-To: <62ABF5D4-238F-4227-8A34-BC677521E21C@ericsson.com> References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> <1028365c1002252213sda034c6wb21a1dd3a1bfa5b5@mail.gmail.com> <62ABF5D4-238F-4227-8A34-BC677521E21C@ericsson.com> Date: Tue, 2 Mar 2010 16:50:10 -0500 Message-ID: <1028365c1003021350w4fceea10m45dc43b33f5a67b6@mail.gmail.com> From: Donald Eastlake To: Acee Lindem Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 02 Mar 2010 14:00:16 -0800 Cc: "rtg-dir@ietf.org" , draft-ietf-trill-rbridge-protocol@tools.ietf.org, Ralph Droms , "trill-chairs@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:50:15 -0000 On Tue, Mar 2, 2010 at 4:35 PM, Acee Lindem wrot= e: > Hi Donald, > Ok - I think you've addressed my issues. I did reread section 4.5 and I t= hink I better understand the multi-destination frame forwarding. Rather tha= n defining a reference protocol state, as is done in RFC 4601, this documen= t defines the requirements and rules for forwarding frames from a given RBr= idge on a chosen distribution tree (both of which are carried in the TRILL = header). > Thanks, > Acee Yes. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street +1-508-634-2066 (home) Milford, MA 01757 USA d3e3e3@gmail.com > On Feb 26, 2010, at 1:13 AM, Donald Eastlake wrote: > >> Hi Acee, >> >> On Wed, Feb 24, 2010 at 2:52 PM, Acee Lindem = wrote: >>> Hi Donald, >>> See inline. >>> >>> On Feb 18, 2010, at 12:07 AM, Donald Eastlake wrote: >>> >>>> Hi Acee, >>>> >>>> Thanks for your detailed comments. >>>> >>>> On Tue, Feb 16, 2010 at 7:50 PM, Acee Lindem wrote: >>>>> ... >>>> >>>>> I think this is a very complex protocol when you consider all the >>>>> pieces and the interaction with IEEE 802.1 bridging. Hence, I think >>>>> interoperable implementations are necessary for document advancement. >>>>> Without them, I would think the intended status should be >>>>> Experimental. >>>> >>>> ... >>>> >>>> I am not claiming the specification is perfect. But I believe it >>>> clearly fits the criterion for Proposed Standard from RFC 2026: >>>> >>>> =A0A Proposed Standard specification is generally stable, has resolved >>>> =A0known design choices, is believed to be well-understood, has receiv= ed >>>> =A0significant community review, and appears to enjoy enough community >>>> =A0interest to be considered valuable. =A0However, further experience >>>> =A0might result in a change or even retraction of the specification >>>> =A0before it advances. >>>> >>>> ... >> >>> The ADs informed me that there is no requirement in the INT area for >>> interoperable implementations or protocol experience. Hence, I guess >>> it is a judgement call. =A0If not two implementations, is there one >>> righteous implementation that interoperates with itself? >> >> There is an open source implementation for Solaris. >> >> (By the way, according to UNH IOL, there are nine companies talking >> with them about interoperability testing. And, although there are no >> hardware TRILL products publicly announced, I was at NANOG 48 earlier >> this week and am at the Ethernet Summit right now. At both there are >> switch company booth personnel who seem quite happy to boast verbally >> about how strongly their companies support TRILL and how they are >> working on implementations.) >> >>>> It is a Local Area Networking protocol based on a well understood >>>> and deployed routing protocol, level 1 IS-IS. >> >>> Well, not exactly. It is ISIS but the hello protocol is modified, it >>> is being used for multicast distribution tree with new rules for tie >>> breaking, and the application supported by the L2 topology >>> information is brand new. >> >> It is my impression that the IESG came to a general conclusion that >> the application of any extra implementation/interoperability >> requirement to the TRILL base protocol specification for Proposed >> Standard would be at the discretion of the Internet Area Directors for >> two reasons: >> =A0 =A0Such additional requirements are best applied to protocols or >> protocol changes that would be expected to have pervasive effects on >> the Internet, such as changes to TCP or BGP, not a local area >> networking protocol. (I'm also adding an explict statement that it is >> not a goal of TRILL to scale beyond the size of exisitng bridged LANs.) >> =A0 =A0 There was no hint that such a requirement would be imposed in th= e >> TRILL Charter or history so this would be an unexpected last-minute >> requirement. >> >>>>> There is a lengthy discussion on determining the inter-RBridge MTU >>>>> for the purposes of TRILL control packets. However, what happens >>>>> if an end-station sends a max-MTU packet and the 40 bytes of >>>>> ethernet outer header and TRILL header cause the packet to be too >>>>> large to be transported between RBridges? >>>> >>>> Obviously, when a frame exceeds MTU on an Ethernet link, it is >>>> generally discarded. (There did not appear to be any interest in the >>>> TRILL WG in adding a link fragmentation protocol for such cases.) >>>> >>>> The consensus of the TRILL WG is that this is not a problem as modern >>>> switches have adequate headroom for headers and encapsulation and the >>>> like. However, to assure safe operation of the TRILL Protocol in case >>>> of limited MTU and to be able to take advantage of a high campus wide >>>> inter-Rbridge link MTU, the TRILL MTU feature was added. >>>> >>>> ... [The draft] >>>> is careful, both in the Section heading and in the text, to say that >>>> the TRILL MTU feature is for "Inter-RBridge Links". It also includes >>>> the following paragraph (where "Sz" has already been defined as the >>>> campus wide minimum inter-Rbridge link MTU): >>>> >>>> =A0Sz has no direct effect on end-stations and is not directly related >>>> =A0to any end-station to end-station "path MTU". Methods of using Sz o= r >>>> =A0any link MTU information gathered by TRILL IS-IS in the traffic >>>> =A0engineering of routes or the determination of any path MTU is beyon= d >>>> =A0the scope of this document. >>>> >>>> A sentence could be add to the above paragraph such as "Native frames >>>> that, after TRILL encapsulation, exceed the MTU of a link on which >>>> they would be sent will generally be discarded." >> >>> Maybe this should be stated explicitly. It seems to me that any >>> draft that adds an additional level of encapsulation (outer ethernet >>> + TRILL header) should have some discussion. >> >> I will add the above sentence in draft version -16 to make this explicit= . >> >>>> By the way, I'm not sure where you get "40 bytes" for TRILL >>>> encapsulation. It adds either 20 bytes or 24 bytes, depending on >>>> whether an outer VLAN tag is sent on the wire (unless there are >>>> options included in the TRILL Header): 12 for the outer destination >>>> and source MAC addresses, possibly 4 for the outer VLAN tag, and 8 for >>>> the TRILL header. In a fully RBridged point-to-point network there >>>> would be no reason to include such an outer VLAN tag on TRILL data or >>>> control frames sent between RBridges, so only 20 bytes would normally >>>> be added. >>>> >>>>> In a TRILL domain with multiple distribution trees, how does an >>>>> ingress RBridge determine which distribution tree to use? I read >>>>> section 4.5 several times and it is not clear to me how the >>>>> ingress RBridge selects a distribution tree (other than everyone >>>>> using the highest priority). =A0Also, nickname terminology is >>>>> confusing. Is the nickname1 tree the distribution tree rooted at >>>>> RBridge 1 or is the nickname space for the distribution trees >>>>> separate? >>>> >>>> On tree selection: Other than the TRILL requirement that the ingress >>>> RBridge announce the set of distribution trees that it might use, what >>>> does it matter? The RBridge campus will operate "correctly" regardless >>>> of what tree(s) are used by the ingress as long as it puts all the >>>> frames that are part of the same order-dependent flow on the same >>>> tree. In the absence of other considerations, it is probably best to >>>> use the tree whose root RBridge is least cost from the ingress >>>> RBridge. But, other than that, such questions as which sub-set of >>>> distribution trees to use if you are multipathing multi-destination >>>> frames seems like an excellent area for implementer creativity and >>>> beyond the scope of this document. >> >>> I may have missed exactly how it works. So, at the ingress, the >>> frame is unicast to the root of the distribution tree selected by >>> the ingress. The root of the distribution tree will then >>> re-encapsulate it and send it on the distribution tree as a >>> multicast. Correct? If so, then I agree with your statement. >> >> No. That's not how it works. With a bidirectional tree, an >> encapsulated packet can be injected anywhere, and travels from that >> point. So the ingress encapsulates it, and it just travels from >> there. The packet is not first unicast to the root and then >> re-encapsulated. The reasons it is good to use a tree whose root is >> least cost from the ingress RBridge are discussed in the first >> paragraph of Section 4.5. >> >> By the way, it turns out that in Section 4.6.1.2 of the current -15 >> draft it does explicitly state that, by default, an RBridge using one >> distribution tree chooses the one whose root is least cost from that >> RBridge. (While not pseudo code, section 4.6 is the most detailed and >> painstaking description in the draft of how to handle every type of >> frame it is possible for an RBridge to receive.) I will also add this >> to Section 4.5 where you were, quite reasonably, looking for it. >> >>>> On nickname terminology: In early drafts, there was only one nickname >>>> per RBridge, so distribution trees could equally well be considered to >>>> be named by a nickname or uniquely determined by their root >>>> RBridge. More recently the option of multiple nicknames per RBridge >>>> was added and now distribution trees are uniquely labeled only by >>>> their nickname. Nicknames are also permitted for pseudo-nodes. There >>>> is only one nickname allocation space. Every nickname in use in a >>>> campus designates either an RBridge or a pseudo-node and one or more >>>> nicknames also each designate a distribution tree. >>>> >>>> With this explanation, do you think that the draft text still needs >>>> clarification and if so do you have any suggestions? >> >>> Maybe section 3.7 could explicitly state that the distribution tree >>> nicknames and the RBridge nicknames are independent of one >>> another. Or if they are not, precisely explain the correlation. >> >> OK, how about adding the following at the end of 3.7.3: >> >> =A0 Every nickname in use in a campus identifies an RBridge (or >> =A0 pseudonode) and every nickname designates a distribution tree >> =A0 rooted at the RBridge (or pseudonode) it identifies. However, only >> =A0 a limited number of these potential distribution trees are actually >> =A0 computed by all the RBridge in a campus and they all compute the >> =A0 same set of distribution trees, as discussed in Section 4.5. >> >>>>> The document should explain the philosophy and usage of confidence >>>>> level with respect to the {port, VLAN, MAC address} tuples. This >>>>> discussion should also tie in the confidence configuration in >>>>> section 5.1. >>>> >>>> Well, how about something like the following new text: >>>> >>>> =A0The confidence level mechanism allows an RBridge campus manager to >>>> =A0cause certain address learning sources to prevail over others. In a >>>> =A0default configuration, without the optional ESADI protocol, >>>> =A0addresses are only learned from observing local native frames and >>>> =A0the decapsulation of received TRILL data frames. Both of these >>>> =A0sources default to confidence level 0x20 so, since learning at an >>>> =A0equal or high confidence overrides previous learning, the learning >>>> =A0in such a default case mimics default 802.1 bridge learning. >>>> >>>> =A0While RBridge campus management policies are beyond the scope of >>>> =A0this document, here are some example types of policies that can be >>>> =A0implemented with the confidence mechanism and the rational for >>>> =A0each: >>>> >>>> =A0o =A0Locally received native frames might be considered more reliab= le >>>> =A0 =A0 than decapsulated frames received from remote parts of the >>>> =A0 =A0 campus. To stop MAC addresses learned from such local frames >>>> =A0 =A0 from being usurped by remotely received forged frames, the >>>> =A0 =A0 confidence in locally learned addresses could be increased or >>>> =A0 =A0 that in addresses learned from remotely sourced decapsulated >>>> =A0 =A0 frames decreased. >>>> >>>> =A0o =A0MAC address information learned through a cryptographically >>>> =A0 =A0 authenticated Layer 2 registration protocol, such as 802.1X wi= th >>>> =A0 =A0 a cryptographically based EAP method, might be considered more >>>> =A0 =A0 reliable than information learned through the mere observation >>>> =A0 =A0 of data frames. When such authenticated learned address >>>> =A0 =A0 information is transmitted via the ESADI protocol, the use of >>>> =A0 =A0 authentication in the TRILL EASDI LSP frames could make >>>> =A0 =A0 tampering with it in transit very difficult. As a result, it >>>> =A0 =A0 might be reasonable to announce such authenticated information >>>> =A0 =A0 via the ESADI protocol with a high confidence, so it would >>>> =A0 =A0 override any alternative learning from data observation. >>>> >>>> =A0Manually configured address information is generally considered >>>> =A0static and so defaults to a confidence of 0xFF while no other >>>> =A0source of such information can be configured to a confidence any >>>> =A0higher than 0xFE. However, for other cases, such as where the >>>> =A0manual configuration is just a starting point which the Rbridge >>>> =A0campus manager wishes to be dynamically overrideable, the >>>> =A0confidence of such manually configured information may be >>>> =A0configured to a lower value. >> >>> This would be good. In the last sentence, do you mean the MAC >>> addresses are dynamically learned or changing the configuration of >>> the confidence level? I suspect the former. >> >> Yes. I will replace "the manual configuration is" with "the manually >> configred MAC addresses are". >> >> Thanks, >> Donald >> >>>>> ... >> >>> Thanks, >>> Acee >>> >>> ... >>>> >>>> Thanks, >>>> Donald [document Editor] >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>>> Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) >>>> 155 Beaver Street >>>> Milford, MA 01757 USA >>>> d3e3e3@gmail.com From d3e3e3@gmail.com Wed Mar 3 09:53:13 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513C828C1D8 for ; Wed, 3 Mar 2010 09:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-0yXjktWYR9 for ; Wed, 3 Mar 2010 09:53:12 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 20BA128C238 for ; Wed, 3 Mar 2010 09:53:11 -0800 (PST) Received: by ewy7 with SMTP id 7so1106133ewy.29 for ; Wed, 03 Mar 2010 09:53:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RhW9Sl6lN/SOja8ytxvVginpkmSnpaahTQvULTp6E6U=; b=dJRa7qfPQYFzjKTohTFHbIdXQaRym+hHqQcWtw9hZvgGo66jI6R4WQaAAoL02Dc+AK pzV0LoXYVKxYBxFJHhLPKrLUk0xcga4coVfzJRCDiDqJ6mJU/cmaan3leSorgHsnrrJK rtsXYWkYrnQkJJd7WI1YRlOVVKXHy3Ec7Ssdw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ILIgJbzhfFv/sF70NajIblC0npGLH8OWvgsV2TS9F1Pq6DaVHr24fQ9k2QsFYYf3tw 6vO9rSrN/b5+TjccsRgtdMEzXxqRrGryYMO2SCYbBMB5KyJ/jdhJYA5dIe5clj3JQ0uQ SLGyZg+Cvu1yp4+BajoqGGHDx6a/fun7r6xlw= MIME-Version: 1.0 Received: by 10.216.165.146 with SMTP id e18mr1139944wel.54.1267638789311; Wed, 03 Mar 2010 09:53:09 -0800 (PST) In-Reply-To: <4B879F65.5020604@cisco.com> References: <31CDB103-D281-4A35-B638-27DFC1D1174A@ericsson.com> <1028365c1002172107p6cc9bb09n7a1ada521402ad64@mail.gmail.com> <0B69B107-42DF-4354-8B6C-CC43DD2BE4E3@ericsson.com> <1028365c1002252213sda034c6wb21a1dd3a1bfa5b5@mail.gmail.com> <4B879F65.5020604@cisco.com> Date: Wed, 3 Mar 2010 12:53:09 -0500 Message-ID: <1028365c1003030953le5f6a0bo283cfcca05679a9f@mail.gmail.com> From: Donald Eastlake To: stbryant@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 03 Mar 2010 10:00:38 -0800 Cc: "rtg-dir@ietf.org" , "trill-chairs@tools.ietf.org" , draft-ietf-trill-rbridge-protocol@tools.ietf.org, Ralph Droms , Acee Lindem , "rtg-ads@tools.ietf.org" Subject: [RTG-DIR] draft-ietf-trill-rbridge-protocol-15.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:53:13 -0000 Hi Stewart, On Fri, Feb 26, 2010 at 5:16 AM, Stewart Bryant wrote: > Donald >> (I'm also adding an explict statement that it is not a goal of >> TRILL to scale beyond the size of exisitng bridged LANs.) > When you say add a statement, are you thinking about a few words > buried deep in the fine print, or a headline statement in capitals > at the front of the form "THIS VERSION OF THE TRILL SPECIFICATION IS > NOT CERTIFIED FOR DEPLOYMENT IN LARGE SCALE WIDE AREA NETWORKS!" On "a few words" I was thinking of a sentence, such as the following: "The TRILL protocol, as specified herein, is designed to be a Local Area Network protocol and not designed with the goal of scaling beyond the size of existing local bridged LANs." On the location of this sentence, a logical place seems to be in the first part of Section 1 just before the sentence that references RFC 5556 ("Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement") but I'm open to other suggestions. On the suggested wording re "certified", I am not a lawyer but it is my understand that stating something is certified for some purpose creates legal liability for failure to perform properly for that purpose. And that for this reason the IETF does not "certify" any of its protocols for any purpose whatsoever. > The concern is that operators may use Trill for hollow core, in > which case a protocol bug could bring down an ISP in a way that > requires rebooting of their entire net. The intent of the warning is > to make sure operators do adequate whitebox testing before they > attempt any such deployment, and as such it needs to be suitably > visible. To the extent that such a possible problem can be mitigated by testing, this seems like a misplaced concern. While users should be encouraged to do testing, for the most part they depend upon the testing done and the assurances given by equipement vendors. I do not think that, at this stage in the development of computer networks, significant vendors implement and ship new protocols without testing and that users such as ISPs only purchase from vendors which do such testing. I believe this is the subtext of RFC 4794. Presumably this is among the reasons that nine vendors have contacted the University of New Hamshire Interoperability Laboratory with a view to arranging and participating in TRILL testing. Such testing is, of course, not an IETF activity. > - Stewart Thanks, Donald (document editor) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd =A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0 +1-508-634-2066 (home) =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street +1-508-634-2066 (home) Milford, MA 01757 USA d3e3e3@gmail.com From fenner@fenron.net Wed Mar 3 12:27:15 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD1928C26B for ; Wed, 3 Mar 2010 12:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QITgvkfRG1wu for ; Wed, 3 Mar 2010 12:27:14 -0800 (PST) Received: from runaway.fenron.net (unknown [206.197.161.144]) by core3.amsl.com (Postfix) with ESMTP id 01C4C28C21D for ; Wed, 3 Mar 2010 12:27:05 -0800 (PST) Received: from runaway.fenron.net (localhost [127.0.0.1]) by runaway.fenron.net (8.13.8/8.13.8) with ESMTP id o21C04qE005219 for ; Mon, 1 Mar 2010 04:00:04 -0800 (PST) (envelope-from fenner@runaway.fenron.net) Received: (from fenner@localhost) by runaway.fenron.net (8.13.8/8.13.8/Submit) id o21C04h4005214 for rtg-dir@ietf.org; Mon, 1 Mar 2010 04:00:04 -0800 (PST) (envelope-from fenner) Date: Mon, 1 Mar 2010 04:00:04 -0800 (PST) Message-Id: <201003011200.o21C04h4005214@runaway.fenron.net> From: fenner@fenron.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) Subject: [RTG-DIR] IESG agenda for 2010-03-04 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 20:27:15 -0000 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2010-03-04). ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of Past Telechats 1.4 List of Remaining Action Items from Last Telechat OUTSTANDING TASKS Last updated: February 22, 2010 o Magnus Westerlund to draft an IESG Statement on BCP 32. o Ron Bonica to propose text for determining when one document updates another. o Lars Eggert to find a designated expert for RFC 5661. o Ralph Droms and Adrian Farrel to update the wiki to reflect circumstances in which implementation is desired before standardization. o Jari Arkko to ask Phil Roberts if he is willing to serve as the designated expert for RFC 5563. If not, Jari will find an expert. o Jari Arkko and Ralph Droms to work with Michelle Cotton to find a new multicast expert. 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Items Area Date RTG Feb 28 LDP Typed Wildcard FEC (Proposed Standard) draft-ietf-mpls-ldp-typed-wildcard-06 [txt] [Open Web Ballot] Note: Loa Andersson (loa@pi.nu) is the document shepherd. Token: Adrian Farrel TSV Feb 27 Transport Protocol Port Randomization Recommendations (BCP) draft-ietf-tsvwg-port-randomization-06 [txt] [Open Web Ballot] Note: James Polk (jmpolk@cisco.com) is the Document Shepherd. Token: Lars Eggert INT Feb 28 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC (Proposed Standard) draft-ietf-dnsext-dnssec-gost-06 [txt] [Open Web Ballot] Note: Olafur Gudmundsson (ogud@ogud.com) is the document shepherd. Token: Ralph Droms Generalized Multi-Protocol Label Switching (GMPLS) Protocol RTG Feb 28 Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN) (Proposed Standard) draft-ietf-ccamp-gmpls-mln-extensions-12 [txt] [Open Web Ballot] Note: Lou Berger (lberger@labn.net) is the Document Shepherd. Token: Adrian Farrel SEC Feb 24 Trust Anchor Management Protocol (TAMP) (Proposed Standard) draft-ietf-pkix-tamp-05 [txt] [Open Web Ballot] Token: Tim Polk 2.1.2 Returning Items Area Date OPS Feb 24 IPFIX Export per SCTP Stream (Proposed Standard) draft-ietf-ipfix-export-per-sctp-stream-06 [txt] [Open Web Ballot] Note: This document was already reviewed and approved by the IESG. The IETF Last Call is redone for Proposed Status following the DISCUSS by Alexey. IPR: * Cisco's Statement of IPR relating to draft-ietf-ipfix-export-per-sctp-stream-02 Token: Dan Romascanu 2.2 Individual Submissions 2.2.1 New Items Area Date SEC Feb 24 GSS-API: Delegate if approved by policy (Proposed Standard) draft-lha-gssapi-delegate-policy-04 [txt] [Open Web Ballot] Token: Tim Polk RAI Feb 28 Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) (Proposed Standard) draft-singh-geopriv-pidf-lo-dynamic-07 [txt] [Open Web Ballot] Note: LC will not have ended by the time this is on agenda but the odds are high there will be zero LC comments. If we decide to approve, I will hold a discuss on any LC comments. Richard Barnes (rbarnes@bbn.com) is the document shepherd. Token: Cullen Jennings Domain Name System (DNS) Security Extensions Mapping for APP Feb 26 the Extensible Provisioning Protocol (EPP) (Proposed Standard) draft-gould-rfc4310bis-06 [txt] Note: Olafur Gudmundsson is the document shepherd Token: Alexey Melnikov 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Items Area Date RAI Feb 28 Updates to Asserted Identity in the Session Initiation Protocol (SIP) (Informational) draft-ietf-sipping-update-pai-09 [txt] [Open Web Ballot] Token: Cullen Jennings SEC Feb 28 The application/pkix-attr-cert Media Type for Attribute Certificates (Informational) draft-ietf-pkix-attr-cert-mime-type-03 [txt] [Open Web Ballot] Note: Shepherd is Steve Kent Token: Tim Polk SEC Feb 24 Heuristics for Detecting ESP-NULL packets (Informational) draft-ietf-ipsecme-esp-null-heuristics-06 [txt] [Open Web Ballot] Note: Yaron Sheffer (yaronf@checkpoint.com) is the document shepherd. Token: Pasi Eronen 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Items Area Date SDP and RTSP extensions defined for 3GPP Packet-switched RAI Feb 24 Streaming Service and Multimedia Broadcast/Multicast Service (Informational) draft-westerlund-mmusic-3gpp-sdp-rtsp-07 [txt] [Open Web Ballot] IPR: * Nokia Corporation's statement about IPR claimed in draft-westerlund-mmusic-3gpp-sdp-rtsp-00.txt Token: Cullen Jennings SEC Feb 28 HMAC-based Extract-and-Expand Key Derivation Function (HKDF) (Informational) draft-krawczyk-hkdf-01 [txt] [Open Web Ballot] Token: Tim Polk 3.2.2 Returning Items NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 5742 responses: 1) The IESG has concluded that there is no conflict between this document and IETF work; 2) The IESG has concluded that this work is related to IETF work done in WG , but this relationship does not prevent publishing; 3) The IESG has concluded that publication could potentially disrupt the IETF work done in WG and recommends not publishing the document at this time; 4) The IESG has concluded that this document violates IETF procedures for and should therefore not be published without IETF review and IESG approval; or 5) The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the document write-up in the Data Tracker, and the document shepherd may supply text for an IESG Note in the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd and agreement that the IESG should request inclusion of the IESG Note. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval Area Date RAI Feb 09 SIP Recording (siprec) Token: Cullen APP Feb 12 Constrained RESTful Environments (core) Token: Lisa TSV Jan 22 Peer to Peer Streaming Protocol (ppsp) Token: Lars 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval Area Date OPS Feb 16 ADSL MIB (adslmib) Token: Dan 5. IAB News We Can Use 6. Management Issues 6.1 Approval of application/exi media type (Alexey Melnikov) 6.2 Approval of application/widget media type (Alexey Melnikov) 6.3 PowerPoint to HTML conversions for the proceedings (Russ Housley) 7. Working Group News From fenner@fenron.net Mon Mar 8 13:05:47 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C6A3A69BE for ; Mon, 8 Mar 2010 13:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtXD77wBPkOE for ; Mon, 8 Mar 2010 13:05:46 -0800 (PST) Received: from runaway.fenron.net (unknown [206.197.161.144]) by core3.amsl.com (Postfix) with ESMTP id 319CF3A69A2 for ; Mon, 8 Mar 2010 13:05:43 -0800 (PST) Received: from runaway.fenron.net (localhost [127.0.0.1]) by runaway.fenron.net (8.13.8/8.13.8) with ESMTP id o28C09Sj055897 for ; Mon, 8 Mar 2010 04:00:09 -0800 (PST) (envelope-from fenner@runaway.fenron.net) Received: (from fenner@localhost) by runaway.fenron.net (8.13.8/8.13.8/Submit) id o28C09QY055896 for rtg-dir@ietf.org; Mon, 8 Mar 2010 04:00:09 -0800 (PST) (envelope-from fenner) Date: Mon, 8 Mar 2010 04:00:09 -0800 (PST) Message-Id: <201003081200.o28C09QY055896@runaway.fenron.net> From: fenner@fenron.com (Bill Fenner) To: rtg-dir@ietf.org (Routing Area Directorate) Subject: [RTG-DIR] IESG agenda for 2010-03-11 telechat. X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:05:47 -0000 IESG Agenda Good approximation of what will be included in the Agenda of next Telechat (2010-03-11). See also: Document on Future IESG Telechat Agendas and IESG Discuss Positions. ----------------------------------------------------------------------- 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of Past Telechats 1.4 List of Remaining Action Items from Last Telechat OUTSTANDING TASKS Last updated: March 4, 2010 o Magnus Westerlund to draft an IESG Statement on BCP 32. o Ron Bonica to propose text for determining when one document updates another. o Lars Eggert to find a designated expert for Remote Procedure Call (RPC). o Lars Eggert to review the TCP Options request and make a recommendation to the IESG. 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Items Area Date INT Mar 08 DNS Zone Transfer Protocol (AXFR) (Proposed Standard) draft-ietf-dnsext-axfr-clarify-13 [txt] [Open Web Ballot] Note: Andrew Sullivan (ajs@shinkuro.com) is the document shepherd. Token: Ralph Droms RAI Mar 05 Specifying Holes in LoST Service Boundaries (Proposed Standard) draft-ietf-ecrit-specifying-holes-02 [txt] Token: Cullen Jennings TSV Mar 05 Transport Protocol Port Randomization Recommendations (BCP) draft-ietf-tsvwg-port-randomization-06 [txt] [Open Web Ballot] Note: James Polk (jmpolk@cisco.com) is the Document Shepherd. Token: Lars Eggert Was deferred by Cullen Jennings on 2010-03-04 RAI Mar 05 Filtering Location Notifications in the Session Initiation Protocol (SIP) (Proposed Standard) draft-ietf-geopriv-loc-filters-10 [txt] Note: The Document Shepherd for this document is Richard Barnes (rbarnes@bbn.com). Token: Cullen Jennings INT Mar 06 IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes (Proposed Standard) draft-ietf-6man-ipv6-subnet-model-08 [txt] [Open Web Ballot] Note: Brian Haberman (brian@innovationslab.net) is the document shepherd. Token: Jari Arkko INT Mar 05 Traffic Selectors for Flow Bindings (Proposed Standard) draft-ietf-mext-binary-ts-04 [txt] [Open Web Ballot] Note: The document shepherd is Marcelo Bagnulo (marcelo@it.uc3m.es). Token: Jari Arkko INT Mar 08 Cryptographic Algorithm Identifier Allocation for DNSSEC (Proposed Standard) draft-ietf-dnsext-dnssec-alg-allocation-02 [txt] [Open Web Ballot] Note: Document shepherd: Andrew Sullivan (ajs@shinkuro.com) Token: Ralph Droms INT Mar 08 SEND Hash Threat Analysis (Proposed Standard) draft-ietf-csi-hash-threat-09 [txt] Note: Document shepherd: Marcelo Bagnulo (marcelo@it.uc3m.es) Token: Ralph Droms TSV Mar 06 The TCP Authentication Option (Proposed Standard) draft-ietf-tcpm-tcp-auth-opt-10 [txt] [Open Web Ballot] Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. IPR: * Juniper's Statement of IPR related to draft-ietf-tcpm-tcp-auth-opt-02 Token: Lars Eggert APP Mar 08 SMTP Service Extension for 8-bit MIME Transport (Standard) draft-ietf-yam-rfc1652bis-03 [txt] [Open Web Ballot] Note: S. Moonesamy (sm+ietf@elandsys.com) is the Document Shepherd. Note that all downrefs were called out during the IETF LC and are as per IESG discussion earlier this year. Token: Alexey Melnikov TSV Mar 06 Cryptographic Algorithms for TCP's Authentication Option, TCP-AO (Proposed Standard) draft-ietf-tcpm-tcp-ao-crypto-02 [txt] [Open Web Ballot] Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Token: Lars Eggert INT Mar 05 IP Mobility Support for IPv4, revised (Proposed Standard) draft-ietf-mip4-rfc3344bis-09 [txt] [Open Web Ballot] Note: Pete McCann (pete.mccann@motorola.com) is the document shepherd. Token: Jari Arkko 2.1.2 Returning Items Area Date SEC Mar 05 Use of the RSA-KEM Key Transport Algorithm in CMS (Proposed Standard) draft-ietf-smime-cms-rsa-kem-11 [txt] [Open Web Ballot] Note: proto shepherd is Blake Ramsdell IPR: * Sean Turner's Statement about IPR related to draft-ietf-smime-cms-rsa-kem-05 belonging to Various Token: Tim Polk 2.2 Individual Submissions 2.2.1 New Items Area Date Domain Name System (DNS) Security Extensions Mapping for APP Mar 05 the Extensible Provisioning Protocol (EPP) (Proposed Standard) draft-gould-rfc4310bis-07 [txt] [Open Web Ballot] Note: Olafur Gudmundsson is the document shepherd Token: Alexey Melnikov INT Mar 07 IANA Rules for PANA (Protocol for Carrying Authentication for Network Access) (Proposed Standard) draft-arkko-pana-iana-02 [txt] [Open Web Ballot] Token: Ralph Droms 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Items Area Date RTG Mar 05 Security Framework for MPLS and GMPLS Networks (Informational) draft-ietf-mpls-mpls-and-gmpls-security-framework-08 [txt] [Open Web Ballot] Note: Martin Vigoureux (martin.vigoureux@alcatel-lucent.com) is the Document Shepherd. Token: Tim Polk Was deferred by Ron Bonica on 2010-03-02 APP Mar 05 Mapping Characters in IDNA (Informational) draft-ietf-idnabis-mappings-05 [txt] [Open Web Ballot] Token: Lisa Dusseault RAI Mar 05 Prefix elements for Road and House Numbers in PIDF-LO (Informational) draft-ietf-geopriv-prefix-00 [txt] Note: The Document Shepherd for this document is Alissa Cooper (acooper@cdt.org). Token: Cullen Jennings INT Mar 05 IP Addressing Model in Ad Hoc Networks (Informational) draft-ietf-autoconf-adhoc-addr-model-02 [txt] [Open Web Ballot] Note: Ryuji Wakikawa (ryuji.wakikawa@gmail.com) is the document shepherd. Token: Jari Arkko RTG Mar 05 Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution (Informational) draft-ietf-l3vpn-mvpn-considerations-06 [txt] [Open Web Ballot] Token: Ross Callon 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Items NONE 3.2.2 Returning Items Area Date INT Mar 05 Pre-authentication Support for PANA (Experimental) draft-ietf-pana-preauth-09 [txt] [Open Web Ballot] IPR: * Toshiba America Research, Inc.'s Statement regardfing IPR claimed in draft-ietf-pana-preauth-01 Token: Jari Arkko 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 5742 responses: 1) The IESG has concluded that there is no conflict between this document and IETF work; 2) The IESG has concluded that this work is related to IETF work done in WG , but this relationship does not prevent publishing; 3) The IESG has concluded that publication could potentially disrupt the IETF work done in WG and recommends not publishing the document at this time; 4) The IESG has concluded that this document violates IETF procedures for and should therefore not be published without IETF review and IESG approval; or 5) The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. The document shepherd must propose one of these responses in the document write-up in the Data Tracker, and the document shepherd may supply text for an IESG Note in the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd and agreement that the IESG should request inclusion of the IESG Note. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval Area Date TSV Jan 22 Peer to Peer Streaming Protocol (ppsp) Token: Lars 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE 5. IAB News We Can Use 6. Management Issues 7. Working Group News From stig@venaas.com Mon Mar 8 14:31:18 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DE33A6AD4 for ; Mon, 8 Mar 2010 14:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J37S8FO1BjjU for ; Mon, 8 Mar 2010 14:31:10 -0800 (PST) Received: from ufisa.uninett.no (ufisa.uninett.no [158.38.152.126]) by core3.amsl.com (Postfix) with ESMTP id A5B403A6A06 for ; Mon, 8 Mar 2010 14:31:09 -0800 (PST) Received: from [IPv6:2001:420:1:fff:0:5efe:10.32.214.37] (unknown [IPv6:2001:420:1:fff:0:5efe:a20:d625]) by ufisa.uninett.no (Postfix) with ESMTP id 4058521AB9; Mon, 8 Mar 2010 23:30:40 +0100 (CET) Message-ID: <4B957A8C.6020404@venaas.com> Date: Mon, 08 Mar 2010 14:30:36 -0800 From: Stig Venaas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: manet-chairs@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-manet-nhdp@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-manet-nhdp-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 22:31:19 -0000 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-manet-nhdp-11.txt Reviewer: Stig Venaas Review Date: March 8, 2010 IETF LC End Date: Unknown Intended Status: Standards Track Summary: The document is well written and I see no major issues with the specification. Although the first minor issue may be important, but I may be missing something. There are also some minor concerns like message size and interoperability. Minor Issues: In S4.1: Each MANET interface: o Is configured with one or more network addresses. All addresses represented by these network addresses MUST be unique to this router at least within its 2-hop neighborhood. All such addresses MUST be unique to this MANET interface, except that an address can be used by more than one MANET interface on the same router if those MANET interfaces are "isolated" from each other (no MANET interface on another router can hear or be heard by two MANET interfaces using overlapping network addresses). This definition seems less strict than what is in last paragraph of 6 (right before 6.1). That says also "one to and one from". I'm wondering if this definition is strict enough. Do you want to allow a topology like the below where there are two links connecting neighbors A and B where A uses the same address "a" on both links? a -- A B -- C a -- Wouldn't then B send messages to C containing "a" twice? Would that be correctly processed by C? Wouldn't C basically treat them as the same announcement twice. And if say one of them is removed, remove both until the next update? In S5.1: This protocol specifies HELLO messages, which are included in packets as defined by [RFC5444]. These packets may be sent either using the "manet" protocol number or the "manet" well-known UDP port number, as specified in [RFC5498]. Should implementations listen for both? Should it be configurable which one to listen too? Are there possible interoperability issues? In S9.3 2. Any Neighbor Tuples whose N_neighbor_addr_list contains the added network address, are removed. Is it OK if it contains an overlapping address? That is if some Tuple has a N_neighbor_addr_list with an element that overlaps this address, or vice versa. In S11.1: If any such network addresses have been added to these Information Bases since the last HELLO message was sent on this MANET interface, or if their status (as indicated by these TLVs and the Values they associate with that network address) have changed since that network address was last reported on this MANET interface, then that network address, and the indicated TLVs, MUST be included in the HELLO message. May not this be too much to fit in a single message? The document should perhaps discuss whether messages should be within the link MTU? Or is fragmentation OK? Is it better to send a large Hello (which may be fragmented) to get new information out fast than to split the info in different Hellos? In general when the info is not changed, then I assume it should be split. But if a router has many local addresses to include, then more bandwidth is used with multiple hello's compared to a single large fragmented one. At least I think some considerations/discussion would be good. Nits: Definition of Network Address in Section 2: Network Address An address plus an associated prefix length. This ^^^ missing - The definition of Heard in Section 2 is: Heard - A MANET interface of router X is considered heard on a MANET interface of a router Y if the latter can receive traffic from the former. I'm not sure what "traffic" is here. As in receiving Hello messages? Maybe there is a more precise term? Definition in Section 2: c = d is a comparison operator Might it be better for unordered lists to define it as "c contains d and d contains c"? And for addresses as, "c overlaps d and d overlaps c"? End of S4.2: received in a HELLO message is considered valid. Appendix F illustrates some example two hop topologies and how they correspond Two-hop? ^^^^^^^ to information in the Information Bases. In S4.3.2 corresponding Link Set and the Neighbor Information Base. Note that when determining whether to include information in a HELLO message, the sender MUST consider all times up to the latest time when it may send its next HELLO message on this MANET interface. What does this mean? Can it be formulated more clearly? I can guess, but it's at best unclear. In S7.1: L_HEARD_time is the time until which the MANET interface of the 1-hop neighbor would be considered heard if not considering link quality; I guess this means it is heard until L_HEARD_time expires, but I think it may be read as "time until it would become heard". That after waiting L_HEARD_time, it will be considered heard. Maybe this could be formulated in a less confusing way? Say "time for which" would for me be much clearer than "time until which". I'm not a native English speaker though, but it will be read by many other non-native speakers as well. This may apply to other places where it says "time until which" too. In S9: the the Interface Information Base and the Neighbor Information Base. ^^^^^^ In S12.1: o The address length as specified in the Message Header is not equal to the length of the addresses used by this router. Shouldn't this be worded differently for a router supporting both IPv4 and IPv6, that is, the router uses addresses of multiple lengths. Stig From ron@bonica.org Mon Mar 15 13:38:08 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4153A6C16 for ; Mon, 15 Mar 2010 13:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.042 X-Spam-Level: *** X-Spam-Status: No, score=3.042 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_RFC_BOGUSMX=1.482, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxVY7QbDwsEU for ; Mon, 15 Mar 2010 13:38:06 -0700 (PDT) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by core3.amsl.com (Postfix) with ESMTP id 7E3023A6B89 for ; Mon, 15 Mar 2010 13:38:05 -0700 (PDT) Received: from [192.168.1.4] ([unknown] [173.66.213.145]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KZC00APGBYXF5N1@vms173011.mailsrvcs.net> for rtg-dir@ietf.org; Mon, 15 Mar 2010 15:37:51 -0500 (CDT) Message-id: <4B9E9A98.5060809@bonica.org> Date: Mon, 15 Mar 2010 16:37:44 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-version: 1.0 To: rtg-ads@tools.ietf.org X-Enigmail-Version: 0.96.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Mailman-Approved-At: Mon, 15 Mar 2010 13:43:25 -0700 Cc: rtg-dir@ietf.org, draft-ietf-lisp@tools.ietf.org, lisp@tools.ietf.org Subject: [RTG-DIR] draft-ietf-lisp-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 20:38:08 -0000 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-06.txt Reviewer: Ron Bonica Review Date: 3/15/2010 IETF LC End Date: TBD Intended Status: EXPERIMENTAL Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Major Issues: o Architectural Issues - Tunnel Liveness - The document says little about what happens when a tunnel connecting iTR to eTR fails? Does temporary black-holing result? What is the restoration mechanism? - UDP Checksum - When an iTR formats the LISP UDP header, it sets the UDP checksum to zero. This is in violation of RFC 768. - The document should say something about cases in which NATs and middle boxes are deployed between iTR and ETR. Will those boxes continue to work? o Caching Issues - The caching policy is not well specified. Therefore, I am worried that the cache might become an easy target for DoS attacks. Consider the following scenario: An opponent discovers the EIDs of 100 hosts behind an ITR. The opponent then sends a steady stream of 50 pps to each of those 100 hosts. Each of those packets has a unique, valid and spoofed source address. Each packet also causes its recipient to send an ICMP port unreachable message to the spoofed source. The ITR cache may be overrun. o Migration issues Considerations - During the migration period, when an ITR receives a packet, it must determine whether that packet's destination address is an EID or an RLOC. The document isn't clear about how the ITR does this. One possibility is to encode that information in the IP address. Another is to query the network to find out. While the first solution may work for IPv6, it won't work well for IPv4. The second solution presents performance problems regardless of IP version. - LISP's goals are best achieved when the entire Internet is surrounded by xTRs (i.e., at the end of migration). However, it is impossible to know when that state has been achieved. The document should say something about when an operator has completed its migration effort and what benefit it can expect to reap at that time. Minor Issues - Terminology section defines many terms that are already commonly understood. Nits: == You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See http://trustee.ietf.org/license-info/) ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. ** There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 10 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC3330 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: LCM: The format is one of the control message formats described in this section. At this time, only Map-Request messages and PIM Join-Prune messages [MLISP] are allowed to be encapsulated. Encapsulating other types of LISP control messages are for further study. When Map-Requests are sent for RLOC-probing purposes (i.e the P-bit is set), they MUST not be sent inside Encapsulated Control Messages. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-02) exists of draft-jen-apt-01 == Outdated reference: A later version (-05) exists of draft-meyer-lisp-cons-03 -- Unexpected draft version: The latest known version of draft-ietf-lisp-interworking is -00, but you're referring to -01. == Outdated reference: A later version (-02) exists of draft-farinacci-lisp-lig-01 == Outdated reference: A later version (-01) exists of draft-meyer-lisp-mn-00 == Outdated reference: A later version (-04) exists of draft-ietf-lisp-ms-03 -- No information found for draft-mathy-lisp-dht - is the name correct? == Outdated reference: A later version (-08) exists of draft-lear-lisp-nerd-04 == Outdated reference: A later version (-02) exists of draft-iannone-openlisp-implementation-01 == Outdated reference: A later version (-05) exists of draft-narten-radir-problem-statement-00 == Outdated reference: A later version (-09) exists of draft-ietf-mip4-rfc3344bis-05 == Outdated reference: draft-ietf-pim-rpf-vector has been published as RFC 5496 -- No information found for draft-handley-p2ppush-unpublished-2007726 - is the name correct? == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533 Summary: 3 errors (**), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. From jmh@joelhalpern.com Mon Mar 15 16:48:34 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F50E3A6862 for ; Mon, 15 Mar 2010 16:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fplXkdB+UijA for ; Mon, 15 Mar 2010 16:48:33 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9E0053A6783 for ; Mon, 15 Mar 2010 16:48:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id B50263233F81; Mon, 15 Mar 2010 16:48:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.187.73] (unknown [207.134.107.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 0C5FD3233F83; Mon, 15 Mar 2010 16:48:40 -0700 (PDT) Message-ID: <4B9EC75A.50604@joelhalpern.com> Date: Mon, 15 Mar 2010 19:48:42 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ron Bonica References: <4B9E9A98.5060809@bonica.org> In-Reply-To: <4B9E9A98.5060809@bonica.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-lisp@tools.ietf.org, lisp@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] draft-ietf-lisp-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 23:48:34 -0000 I wanted to highlight one issue, and see what folks think the right path is for it. Ron Bonica wrote: > Hello, ... > Major Issues: > > o Architectural Issues ... > - UDP Checksum - When an iTR formats the LISP UDP header, it sets the > UDP checksum to zero. This is in violation of RFC 768. ... That is not a violation of RFC 768. For IPv4, a 0 UDP checksum is a long established practice, and widely documented and used. However, there is an issue for IPv6. The IPv6 specifications changed the rules for UDP, as a corollary of removing the IP header checksum. In IPv6, UDP is required to always have a valid checksum. This creates a significant problem for ANY high volume tunneling protocol. Not just LISP. Assumption: If you have a high volume tunnel, you want to allow ECMP (or LAG) logic to properly handle traffic within the tunnel. But, ECMP / LAG logic in current deployment, for IPv6 uses the src/dst IPv6 address, the protocol, and the port numbers. This means that for a high volume tunnel, you need port numbers in a protocol that the ECMP logic will accept. Only TCP and UDP currently meet that constraint. Constraint: Many high end routers can not calculate a valid UDP checksum over the entire content of the body of the packet, which is what is required by the IPv6 RFCs. This puts us in a VERY difficult spot. We can pretend that there are no high volume tunnels in the internet. (This would seem inappropriate for an experiment interested in scaling properties, even if the experiment itself may not achieve the bandwidths needed for this to be a major issue.) We can violate the RFC. We can try to change the RFC (but the transport area is VERY reluctant to relax this rule.) In the long run, I believe that the right answer is to encourage vendors to include the IPv6 flow label in their ECMP (or LAG) hash. However, I do not see how we can hold up experimental work going on now waiting for that eventual future. I do anticipate a fight with transport about this. But it should be clearly understood that this particular issue has MUCH larger scope than just LISP. Yours, Joel M. Halpern From rbonica@juniper.net Mon Mar 15 17:03:11 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21E803A6B75 for ; Mon, 15 Mar 2010 17:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.26 X-Spam-Level: X-Spam-Status: No, score=-106.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrbSbK6p7rTj for ; Mon, 15 Mar 2010 17:03:10 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 445C23A6BA8 for ; Mon, 15 Mar 2010 17:01:53 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKS57KbFsFpyP/Rcj3bZQRqWVq3PYphTvW@postini.com; Mon, 15 Mar 2010 17:02:02 PDT Received: from [172.28.134.30] (172.28.134.30) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 15 Mar 2010 16:59:25 -0700 Message-ID: <4B9EC9DA.2060604@juniper.net> Date: Mon, 15 Mar 2010 19:59:22 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Joel M. Halpern" References: <4B9E9A98.5060809@bonica.org> <4B9EC75A.50604@joelhalpern.com> In-Reply-To: <4B9EC75A.50604@joelhalpern.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-lisp@tools.ietf.org, lisp@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] draft-ietf-lisp-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 00:03:11 -0000 Joel, Good catch! Thanks for catching my error! Ron Joel M. Halpern wrote: > I wanted to highlight one issue, and see what folks think the right path > is for it. > > Ron Bonica wrote: >> Hello, > ... >> Major Issues: >> >> o Architectural Issues > ... >> - UDP Checksum - When an iTR formats the LISP UDP header, it sets the >> UDP checksum to zero. This is in violation of RFC 768. > ... > > That is not a violation of RFC 768. For IPv4, a 0 UDP checksum is a > long established practice, and widely documented and used. > > However, there is an issue for IPv6. The IPv6 specifications changed > the rules for UDP, as a corollary of removing the IP header checksum. In > IPv6, UDP is required to always have a valid checksum. > > This creates a significant problem for ANY high volume tunneling > protocol. Not just LISP. > Assumption: If you have a high volume tunnel, you want to allow ECMP (or > LAG) logic to properly handle traffic within the tunnel. > But, ECMP / LAG logic in current deployment, for IPv6 uses the src/dst > IPv6 address, the protocol, and the port numbers. > This means that for a high volume tunnel, you need port numbers in a > protocol that the ECMP logic will accept. Only TCP and UDP currently > meet that constraint. > > Constraint: Many high end routers can not calculate a valid UDP > checksum over the entire content of the body of the packet, which is > what is required by the IPv6 RFCs. > > This puts us in a VERY difficult spot. > We can pretend that there are no high volume tunnels in the internet. > (This would seem inappropriate for an experiment interested in scaling > properties, even if the experiment itself may not achieve the bandwidths > needed for this to be a major issue.) > We can violate the RFC. > We can try to change the RFC (but the transport area is VERY reluctant > to relax this rule.) > > In the long run, I believe that the right answer is to encourage vendors > to include the IPv6 flow label in their ECMP (or LAG) hash. > However, I do not see how we can hold up experimental work going on now > waiting for that eventual future. > > I do anticipate a fight with transport about this. > But it should be clearly understood that this particular issue has MUCH > larger scope than just LISP. > > Yours, > Joel M. Halpern > > From thomas.morin@orange-ftgroup.com Tue Mar 16 02:09:51 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 796363A682F for ; Tue, 16 Mar 2010 02:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHwpnp67SY0m for ; Tue, 16 Mar 2010 02:09:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by core3.amsl.com (Postfix) with ESMTP id 4CDAF3A67FA for ; Tue, 16 Mar 2010 02:09:50 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id CF1843745E9 for ; Tue, 16 Mar 2010 10:09:53 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B973E3840C6 for ; Tue, 16 Mar 2010 10:09:53 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 10:09:53 +0100 Received: from [10.193.15.39] ([10.193.15.39]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 10:09:52 +0100 Message-ID: <2436_1268730593_4B9F4AE1_2436_277010_1_4B9F4AE0.8030508@orange-ftgroup.com> Date: Tue, 16 Mar 2010 10:09:52 +0100 From: Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: rtg-dir@ietf.org References: <4B9E9A98.5060809@bonica.org> <4B9EC75A.50604@joelhalpern.com> In-Reply-To: <4B9EC75A.50604@joelhalpern.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Mar 2010 09:09:52.0792 (UTC) FILETIME=[703C0980:01CAC4E8] X-PMX-Version: 5.5.7.378829, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.3.16.83931 Subject: Re: [RTG-DIR] draft-ietf-lisp-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 09:09:51 -0000 Joel M. Halpern : > > However, there is an issue for IPv6. The IPv6 specifications changed > the rules for UDP, as a corollary of removing the IP header checksum. > In IPv6, UDP is required to always have a valid checksum. > > This creates a significant problem for ANY high volume tunneling > protocol. Not just LISP. > [...] > [...] it should be clearly understood that this particular issue has > MUCH larger scope than just LISP. The very same UDPv6 checksum issue is being faced by the AMT protocol in the mboned working group (draft-ietf-mboned-auto-multicast). See eg. the thread starting at http://www.ietf.org/mail-archive/web/mboned/current/msg00904.html . They seem optimistic that the current rule on v6 UDP would get relaxed. -Thomas ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ******************************** From jmh@joelhalpern.com Tue Mar 16 04:17:52 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0A73A6A36 for ; Tue, 16 Mar 2010 04:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ka788zluc9TF for ; Tue, 16 Mar 2010 04:17:51 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 616D03A6A2F for ; Tue, 16 Mar 2010 04:17:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0DF9B3234439; Tue, 16 Mar 2010 04:18:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.187.73] (unknown [207.134.107.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id ACBA4323443B; Tue, 16 Mar 2010 04:17:59 -0700 (PDT) Message-ID: <4B9F68E8.1080808@joelhalpern.com> Date: Tue, 16 Mar 2010 07:18:00 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: thomas.morin@orange-ftgroup.com References: <4B9E9A98.5060809@bonica.org> <4B9EC75A.50604@joelhalpern.com> <2436_1268730593_4B9F4AE1_2436_277010_1_4B9F4AE0.8030508@orange-ftgroup.com> In-Reply-To: <2436_1268730593_4B9F4AE1_2436_277010_1_4B9F4AE0.8030508@orange-ftgroup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org Subject: Re: [RTG-DIR] draft-ietf-lisp-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 11:17:52 -0000 Yes, the AMT folks ran into a different version of the same problem. I am not fully conversant with their concerns, but as I understand it, ECMP treatment in routers is not the primary driver for them. As such, they are considering solutions like UDP-lite. This would work fairly quickly for end systems, and like the use of flow-spec would be sufficient in the routers once it was deployed. But getting from here to there seems to be an obstacle. (For those who have not followed every possible debate in our community, UDP-lite is an alternative carried protocol that mostly looks like UDP. However, only checksums the IP header and the UDP header, which is far more impplementable at high rates or in routers.) Yours, Joel thomas.morin@orange-ftgroup.com wrote: > Joel M. Halpern : >> However, there is an issue for IPv6. The IPv6 specifications changed >> the rules for UDP, as a corollary of removing the IP header checksum. >> In IPv6, UDP is required to always have a valid checksum. >> >> This creates a significant problem for ANY high volume tunneling >> protocol. Not just LISP. >> [...] >> [...] it should be clearly understood that this particular issue has >> MUCH larger scope than just LISP. > > The very same UDPv6 checksum issue is being faced by the AMT protocol in > the mboned working group (draft-ietf-mboned-auto-multicast). See eg. > the thread starting at > http://www.ietf.org/mail-archive/web/mboned/current/msg00904.html . They > seem optimistic that the current rule on v6 UDP would get relaxed. > > -Thomas > > > ********************************* > This message and any attachments (the "message") are confidential and intended solely for the addressees. > Any unauthorised use or dissemination is prohibited. > Messages are susceptible to alteration. > France Telecom Group shall not be liable for the message if altered, changed or falsified. > If you are not the intended addressee of this message, please cancel it immediately and inform the sender. > ******************************** > > From Adrian.Farrel@huawei.com Sun Mar 21 11:48:57 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1AAD3A67E9; Sun, 21 Mar 2010 11:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dDjXwuqicq9; Sun, 21 Mar 2010 11:48:57 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 18A503A6784; Sun, 21 Mar 2010 11:48:57 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZN00JCBAY1RW@usaga03-in.huawei.com>; Sun, 21 Mar 2010 13:49:13 -0500 (CDT) Received: from your029b8cecfe ([130.129.25.211]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZN008QWAY0LV@usaga03-in.huawei.com>; Sun, 21 Mar 2010 13:49:13 -0500 (CDT) Date: Sun, 21 Mar 2010 18:48:28 +0000 From: Adrian Farrel To: rtg-chairs@ietf.org Message-id: <452D6783B0E74CC18593FD2600382692@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: Routing Area Directorate , routing-discussion@ietf.org, Stewart Bryant Subject: [RTG-DIR] Routing ADs Open Office in Anaheim X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2010 18:48:57 -0000 Hi, The Routing ADs will be open for business from 2pm to 4.30pm today (Sunday). We will be meeting in "Mezzanine 1" on the 3rd floor. You are all *very* welcome to drop in any time to: - raise issues - ask questions - give advice - give gifts - see who we are Adrian From jgs@juniper.net Mon Mar 22 09:22:17 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194B83A6B2A for ; Mon, 22 Mar 2010 09:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[AWL=2.602, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RdMQ3bakZew for ; Mon, 22 Mar 2010 09:22:15 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 0849A28C171 for ; Mon, 22 Mar 2010 09:21:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS6eZMKVLK3x1pDLLtUR5Jaq7qTEJtvUm@postini.com; Mon, 22 Mar 2010 09:22:09 PDT Received: from [172.24.234.36] (172.24.234.36) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.393.1; Mon, 22 Mar 2010 09:20:32 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2010 09:20:26 -0700 References: <20100308211357.GA19638@vaf-lnx1.cisco.com> To: Message-ID: MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [RTG-DIR] Fwd: [lisp] RtgDir review: draft-ietf-lisp-alt-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:22:17 -0000 Fwd 2 of 3 Begin forwarded message: > From: Vince Fuller > Date: March 8, 2010 1:13:57 PM PST > To: John Scudder > Cc: "lisp@ietf.org" , = "draft-ietf-lisp-alt@tools.ietf.org" = , "lisp-chairs@tools.ietf.org" = , "rtg-dir@tools.ietf.org" = , "rtg-ads@tools.ietf.org" = , "vaf@cisco.com" > Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-alt-03.txt >=20 >> The term "LISP header" is defined in the LISP document. It is = slightly >> more than just an encapsulating IP header as it also includes a UDP >> header (required for LAG traffic distribution according to those with >> operational networks who have worked with the authors) with = destination >> port 4141 (LISP-encapsulated user data) or 4142 (LISP control). For >> LISP control messages, there are additional defined fields. >=20 > FYI, as Darrel pointed out in private email, I typod the port numbers > above. They should be 4341 (LISP user data) and 4342 (LISP control). >=20 > --Vince From jgs@juniper.net Mon Mar 22 09:23:16 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585B828C199 for ; Mon, 22 Mar 2010 09:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.388 X-Spam-Level: X-Spam-Status: No, score=-3.388 tagged_above=-999 required=5 tests=[AWL=2.082, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsyLrhAWfSvN for ; Mon, 22 Mar 2010 09:23:12 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 3C6343A69AA for ; Mon, 22 Mar 2010 09:22:03 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS6eZOyUwltKy38Y6qPSuBi2CyHWH4dtX@postini.com; Mon, 22 Mar 2010 09:22:21 PDT Received: from [172.24.234.36] (172.24.234.36) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.393.1; Mon, 22 Mar 2010 09:20:37 -0700 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Mar 2010 09:20:36 -0700 References: <5257ED27-DC30-408D-9ABE-14106697F170@juniper.net> To: Message-ID: <42E5CD48-DA19-4E5E-B4D3-4230A52E43DF@juniper.net> MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [RTG-DIR] Fwd: [lisp] RtgDir review: draft-ietf-lisp-alt-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:23:16 -0000 Fwd 3 of 3 Begin forwarded message: > From: "John G. Scudder" > Date: March 21, 2010 3:36:16 PM PDT > To: Vince Fuller > Cc: "lisp@ietf.org" , = "draft-ietf-lisp-alt@tools.ietf.org" = , "lisp-chairs@tools.ietf.org" = , "rtg-dir@tools.ietf.org" = , "rtg-ads@tools.ietf.org" = > Subject: Re: [lisp] RtgDir review: draft-ietf-lisp-alt-03.txt >=20 > Vince, >=20 > Thanks for your reply. I'll look over the revised doc as soon as I = can; in the meantime a couple of quick comments. >=20 > On Mar 8, 2010, at 2:08 PM, Vince Fuller wrote: >>> 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. >>=20 >> This is partly addressed (no pun intended) by changes to the = aggregation >> example, which now specifically discusses how holes are handled. = There is >> also new clarifying text that emphasizes that the ALT is a tunneled >> topology, so re-homing attachment points to facilitate aggregation = should >> be relatively simple. A more thorough discussion of business = relationships >> is, IMHO, beyond the scope of a technical IETF document and it a = matter >> for further study as EID/RLOC separation technology evolves. >=20 > I'd be satisfied if the document pointed out that users will need to = acquire their EID space from somewhere and will be tied to that supplier = unless they renumber their site. I do agree that the specifics of the = business (or non-profit, or whatever) relationship between the site and = the EID supplier is out of scope. What I think is important is that a = fresh reader not mistakenly think that LISP eliminates all such = relationships making sites completely fancy-free. I think this is a = nuance that could be fairly easily overlooked by someone new to the = topic. >=20 > If you think the tie to the EID supplier is not fundamental, I'd be = very interested in hearing why. >=20 >>> S13, References. Surely [LISP] must be a normative reference? >>> [LISP-MS] also seems to be. >>=20 >> Fixed. The distinction between "normative reference" and "informative >> reference" in IETF procedural-speak is somewhat lost on me. >=20 > I'm hardly an authority but my heuristic is that if I can understand = and implement the spec without looking at the reference, the reference = is informative. If I need to look at the referenced document, it's = normative. >=20 > Regards, >=20 > --John > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jgs@juniper.net Mon Mar 22 09:21:56 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3755528C17C for ; Mon, 22 Mar 2010 09:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.284 X-Spam-Level: ** X-Spam-Status: No, score=2.284 tagged_above=-999 required=5 tests=[AWL=-5.098, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_HTML_SINGLETS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSfVv2LhDnXN for ; Mon, 22 Mar 2010 09:21:44 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id E2F973A69C2 for ; Mon, 22 Mar 2010 09:21:37 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKS6eZI80Mo2CCKOQYPoJbP8bAyD404yks@postini.com; Mon, 22 Mar 2010 09:21:56 PDT Received: from [172.24.234.36] (172.24.234.36) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.1.393.1; Mon, 22 Mar 2010 09:19:50 -0700 From: "John G. Scudder" Content-Type: multipart/mixed; boundary="Apple-Mail-15-1057297310" Date: Mon, 22 Mar 2010 09:19:49 -0700 References: <20100308190821.GA17921@vaf-lnx1.cisco.com> To: Message-ID: <38B01B9B-C331-4D11-B1C5-65ECBB9978C0@juniper.net> MIME-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Mon, 22 Mar 2010 10:35:54 -0700 Subject: [RTG-DIR] Fwd: RtgDir review: draft-ietf-lisp-alt-03.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:21:56 -0000 --Apple-Mail-15-1057297310 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" This had the wrong address for rtg-dir. I'll forward a few more in the = same thread following this. --John Begin forwarded message: > From: Vince Fuller > Date: March 8, 2010 11:08:21 AM PST > To: John Scudder > Cc: "rtg-ads@tools.ietf.org" , = "rtg-dir@tools.ietf.org" , = "draft-ietf-lisp-alt@tools.ietf.org" = , "lisp-chairs@tools.ietf.org" = , "lisp@ietf.org" > Subject: Re: RtgDir review: draft-ietf-lisp-alt-03.txt >=20 > Hi John- >=20 > Thanks for the thorough review and comments. I have incorporated most = of > them in to the latest draft, which is attached along with diffs from = -02. >=20 > To respond specifically to several several of your points: >=20 >> 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. >=20 > This document is intended to describe, in general terms, how to build = the > ALT, using BGP and GRE, and what the different components of the ALT = are. > A companion deployment guide document, which will cover more specific > operational aspects of the ALT, is already in the works. >=20 >> 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. >=20 > See above regarding the deployment guide. The issue of distinguishing = an > EID from a "conventional IP address" is a difficult one that is = inherent > in trying to build a id/locator separation system that uses = "addresses" > that are backward-compatible with existing host usage. >=20 >> 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. >=20 > Added to the Security Considerations section. >=20 >> 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. >=20 > Discussion added about rate-limiting of and possible filtering of = non-ALT- > Datagrams (Map Reqeusts and Data Probes) added as appropriate. >=20 >> 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. >=20 > Section rewritten with clarifying text added. >=20 >> 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. >=20 > This is partly addressed (no pun intended) by changes to the = aggregation > example, which now specifically discusses how holes are handled. There = is > also new clarifying text that emphasizes that the ALT is a tunneled > topology, so re-homing attachment points to facilitate aggregation = should > be relatively simple. A more thorough discussion of business = relationships > is, IMHO, beyond the scope of a technical IETF document and it a = matter > for further study as EID/RLOC separation technology evolves. >=20 >> 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. >=20 > References to RFC 2119 and use of terminology have been removed. >=20 >> 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? >=20 > Section 2 rewritten to address this. >=20 >> 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". >=20 > The term "LISP header" is defined in the LISP document. It is slightly > more than just an encapsulating IP header as it also includes a UDP > header (required for LAG traffic distribution according to those with > operational networks who have worked with the authors) with = destination > port 4141 (LISP-encapsulated user data) or 4142 (LISP control). For > LISP control messages, there are additional defined fields. >=20 >> 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]?). >=20 > The "or its proxy" is an obsolete term from an early version of the > document and has been removed. Thanks for catching this. >=20 >> 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. >=20 > This section has been reworded to more clearly describe when Data = Probes > may be used, which is basically only when doing specific experiments > intended to demonstrate whether they are useful. We expect that such > experiments will be completed before LISP and LISP+ALT move towards > standards adoption (if that occurs) and that revised versions of the > specs will either eliminate Data Probes completely or will provide a > more thorough description of how and when it is appropriate to use = them. >=20 >> 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? >=20 > This tortured text was attempting to describe negatve cache entries = and > dates back to an early version of the document before we'd formalized > what that meant. I have rewritten it for clarity. >=20 >> 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. >=20 > Rewritten and expanded to explicitly describe how holes works. >=20 >> 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. >=20 > Rewritten pretty much as you suggested. >=20 >> 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. >=20 > Rewitten to point out this trade-off. >=20 >> 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. >=20 > Rewritten and expanded to better explain this. >=20 >> 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]. >=20 > In re-reading this section, I agree that it did a poor job of = combining > two concepts (ALT stability and traffic engineering) that are only > indirectly related. I have split the discussion into two subsections > and have rewritten/expanded both to better explain the intention. >=20 >> 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 traf fic >> 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. >=20 > This is an area of the LISP effort that is in the midst of a great = deal > of evolution right now. The authors are actively working to engage the > operational community in a dicussion to figure out what traffic = engineering > capabilities are needed and how best to incorporate those capabilities = into > LISP and the LISP mapping database. If you're interested in = participating > in these discussions, I'd very much welcome your input. >=20 >> 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. >=20 > Rewritten to clarify how and why the ALT can help improve stability. >=20 >> 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. >=20 > I believe more details will come out of development of the ALT = deployment > document. >=20 >> S11.3 the citation for S-BGP (not sBGP) is wrong. >=20 > Fixed. >=20 >> S13, References. Surely [LISP] must be a normative reference? >> [LISP-MS] also seems to be. >=20 > Fixed. The distinction between "normative reference" and "informative > reference" in IETF procedural-speak is somewhat lost on me. >=20 >> The final paragraph of S.2 summarizes most of the following sections >> other than S.7 and sections 10+. Seemed odd to omit those. >=20 > Fixed. Probably an oversight as additional sections were added. >=20 >> The definition of RLOC should probably mention that "locator" is >> used interchangeably with "RLOC". Or, the uses of "locator" could >> be replaced by "RLOC". >=20 > Fixed. >=20 >> 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.) >=20 > Eliminated the acronym use and spelled-out "destination IP address". >=20 >> 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?) >=20 > Yes, it is "at the edge". Fixed, though I haven't added a specific > definition of "the edge". >=20 >> S5.1 talks about Data Probes without mentioning that they're = discouraged. >=20 > Fixed. >=20 >> 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. >=20 > Fixed. Good catch, thanks. >=20 >> 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. >=20 > Mostly removed except where I thought the emphasis was needed. >=20 >> S9.1 "TCP-connected ETRs". These are not defined. >=20 > Obsolete reference, removed. >=20 >> The [Interworking] reference has expired. >=20 > Updated reference. >=20 >> In addition, the following minor changes. This is against the >> version that was sent to lisp@ietf.org on Feb 23: >>=20 >> 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 > ... >=20 > Is there some context missing from this list of diffs? I can't see any > differences in the text other than spacing. >=20 > --Vince --Apple-Mail-15-1057297310 Content-Disposition: attachment; filename="draft-ietf-lisp-alt-03.txt" Content-Type: text/plain; name="draft-ietf-lisp-alt-03.txt" Content-Transfer-Encoding: quoted-printable =0D =0D =0D Network Working Group V. Fuller=0D= Internet-Draft D. Farinacci=0D= Intended status: Experimental D. Meyer=0D= Expires: September 9, 2010 D. Lewis=0D= Cisco=0D= March 8, 2010=0D= =0D =0D LISP Alternative Topology (LISP+ALT)=0D draft-ietf-lisp-alt-03.txt=0D =0D Abstract=0D =0D This document describes a simple mapping database to be used by the=0D= Locator/ID Separation Protocol (LISP) to find Endpoint Identifier=0D (EID) to Routing Locator (RLOC) mappings. Termed the Alternative=0D Logical Topology (ALT), the database is built as an overlay network=0D= on the public Internet using the Border Gateway Protocol (BGP) and=0D the Generic Routing Encapsulation (GRE). Using these proven=0D protocols, the ALT can be built and deployed relatively quickly=0D without major changes to the existing routing infrastructure.=0D =0D Status of this Memo=0D =0D This Internet-Draft is submitted to IETF in full conformance with the=0D= provisions of BCP 78 and BCP 79.=0D =0D Internet-Drafts are working documents of the Internet Engineering=0D Task Force (IETF), its areas, and its working groups. Note that=0D other groups may also distribute working documents as Internet-=0D Drafts.=0D =0D Internet-Drafts are draft documents valid for a maximum of six months=0D= and may be updated, replaced, or obsoleted by other documents at any=0D= time. It is inappropriate to use Internet-Drafts as reference=0D material or to cite them other than as "work in progress."=0D =0D The list of current Internet-Drafts can be accessed at=0D http://www.ietf.org/ietf/1id-abstracts.txt.=0D =0D The list of Internet-Draft Shadow Directories can be accessed at=0D http://www.ietf.org/shadow.html.=0D =0D This Internet-Draft will expire on September 9, 2010.=0D =0D Copyright Notice=0D =0D Copyright (c) 2010 IETF Trust and the persons identified as the=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 1]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D document authors. All rights reserved.=0D =0D This document is subject to BCP 78 and the IETF Trust's Legal=0D Provisions Relating to IETF Documents=0D (http://trustee.ietf.org/license-info) in effect on the date of=0D publication of this document. Please review these documents=0D carefully, as they describe your rights and restrictions with respect=0D= to this document. Code Components extracted from this document must=0D= include Simplified BSD License text as described in Section 4.e of=0D the Trust Legal Provisions and are provided without warranty as=0D described in the BSD License.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 2]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D Table of Contents=0D =0D 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4=0D= 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5=0D= 3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 8=0D= 3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8=0D= 3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 9=0D= 3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 9=0D= 3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 9=0D= 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9=0D= 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 10=0D= 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11=0D= 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 12=0D= 4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 12=0D= 4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 14=0D= 5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 15=0D= 5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 15=0D= 5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 15=0D= 6. BGP configuration and protocol considerations . . . . . . . . 17=0D= 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 17=0D= 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 17=0D= 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 18=0D= 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 18=0D= 7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 18=0D= 7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 19=0D= 8. Connecting sites to the ALT network . . . . . . . . . . . . . 20=0D= 8.1. ETRs originating information into the ALT . . . . . . . . 20=0D= 8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 20=0D= 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22=0D= 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23=0D= 10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 23=0D= 10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 24=0D= 10.3. Use of new IETF standard BGP Security mechanisms . . . . . 24=0D= 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25=0D= 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26=0D= 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26=0D= 12.2. Informative References . . . . . . . . . . . . . . . . . . 26=0D= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27=0D= =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 3]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 1. Introduction=0D =0D This document describes the LISP+ALT mapping database, to be used by=0D= LISP to find EID-to-RLOC mappings. The ALT network is built using=0D the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol=0D= extension [RFC2858], and the Generic Routing Encapsulation (GRE,=0D [RFC2784]) to construct an overlay nnetwork of devices (ALT Routers)=0D= which operate on EID-prefixes and use EIDs as forwarding=0D destinations.=0D =0D ALT Routers advertise hierarchically-delegated segments of the EID=0D namespace (i.e., prefixes) toward the rest of the ALT; they also=0D forward traffic destined for an EID covered by one of those prefixes=0D= toward the network element which is authoritative for that EID (i.e.=0D= is the origin of the advertisement of the EID-to-RLOC mapping which=0D= applies to that EID). Map Resolvers (MRs; see [LISP-MS]) and, in=0D some cases, Ingress Tunnel Routers (ITRs) use this overlay to send=0D mapping requests (using [LISP]) to the Egress Tunnel Routers (ETRs)=0D= that hold the EID-to-RLOC mappings for a particular EID-prefix=0D =0D It is important to note that the ALT does not distibute actual EID-=0D= to-RLOC mappings. What it does provide is a forwarding path from an=0D= ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which=0D holds that mapping. The ITR/MR uses this path to send an ALT=0D Datagram (see Section 3) to an ETR which then responds with a Map-=0D Reply containing the needed mapping information.=0D =0D One design goal for LISP+ALT is to use existing technology wherever=0D= possible. To this end, the ALT is intended to be built using off-=0D the-shelf routers which already implement the required protocols (BGP=0D= and GRE); little, if any, LISP-specific modifications should be=0D needed for such devices to be deployed on the ALT. Note, though,=0D that organizational and operational considerations suggest that ALT=0D= Routers be both logically and physically separate from the "native"=0D= Internet packet transport system; deploying this overlay on those=0D routers which are already participating in the global routing system=0D= and actively forwarding Internet traffic is not recommended.=0D =0D The remainder of this document is organized as follows: Section 2=0D provides the definitions of terms used in this document. Section 3=0D= outlines the basic LISP 1.5 model. Section 4 provides a basic=0D overview of the LISP Alternate Topology architecture, and Section 5=0D= describes how the ALT uses BGP to propagate Endpoint Identifier=0D reachability over the overlay network and Section 6 describes other=0D= considerations for using BGP on the ALT. Section 7 describes the=0D construction of the ALT aggregation hierarchy, and Section 8=0D discusses how LISP+ALT elements are connected to form the overlay=0D network.=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 4]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 2. Definition of Terms=0D =0D LISP+ALT operates on two name spaces and introduces a new network=0D element, the LISP+ALT Router (see below). This section provides=0D high-level definitions of the LISP+ALT name spaces, network elements,=0D= and message types.=0D =0D Alternative Logical Topology (ALT): The virtual overlay network=0D made up of tunnels between LISP+ALT Routers. The Border Gateway=0D= Protocol (BGP) runs between ALT Routers and is used to carry=0D reachability information for EID-prefixes. The ALT provides a way=0D= to forward Map-Requests (and, if supported, Data Probes) toward=0D the ETR that "owns" and EID-prefix. As a tunneled overlay, its=0D performance is expected to be quite limited so use of it to=0D forward high-bandwidth flows of Data Probes is strongly=0D discouraged (see Section 3.3 for additional discussion).=0D =0D Legacy Internet: The portion of the Internet which does not run=0D LISP and does not participate in LISP+ALT.=0D =0D ALT Router: The devices which run on the ALT. The ALT is a static=0D= network built using tunnels between ALT Routers. These routers=0D are deployed in a roughly-hierarchical mesh in which routers at=0D each level in the topology are responsible for aggregating EID-=0D prefixes learned from those logically "below" them and advertising=0D= summary prefixes to those logically "above" them. Prefix learning=0D= and propagation between ALT Routers is done using BGP. An ALT=0D Router at the lowest level, or "edge" of the ALT, learns EID-=0D prefixes from its "client" ETRs. See Section 3.1 for a=0D description of how EID-prefixes are learned at the "edge" of the=0D= ALT. See also Section 6 for details on how BGP is configured=0D between the different network elements. When an ALT Router=0D receives an ALT Datagram, it looks up the destination EID in its=0D= forwarding table (composed of EID prefix routes it learned from=0D neighboring ALT Routers) and forwards it to the logical next-hop=0D= on the overlay network.=0D =0D Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit (for ipv6) value=0D= used to identify the ultimate source or destination for a LISP-=0D encapsulated packet. See [LISP] for details.=0D =0D EID-prefix: A set of EIDs delegated in a power-of-two block. EID-=0D= prefixes are routed on the ALT (not on the global Internet) and=0D are expected to be assigned in a hierarchical manner such that=0D they can be aggregated by ALT Routers. Such a block is=0D characterized by a prefix and a length. Note that while the ALT=0D= routing system considers an EID-prefix to be an opaque block of=0D EIDs, an end site may put site-local, topologically-relevant=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 5]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D structure (subnetting) into an EID-prefix for intra-site routing.=0D= =0D Aggregated EID-prefixes: A set of individual EID-prefixes that have=0D= been aggregated in the [RFC4632] sense.=0D =0D Map Server (MS): An edge ALT Router that provides a registration=0D= function for non-ALT-connected ETRs, originates EID-prefixes into=0D= the ALT on behalf of those ETRs, and forwards Map-Reqeusts to=0D them. See [LISP-MS] for details.=0D =0D Map Resolver (MR): An edge ALT Router that accepts an Encapsulated=0D= Map-Reqeust from a non-ALT-connected ITR, decapsulates it, and=0D forwards it on to the ALT toward the ETR which owns the requested=0D= EID-prefix. See [LISP-MS] for details.=0D =0D Ingress Tunnel Router (ITR): A router which sends LISP Map-=0D Requests or encapsulates IP datagrams with LISP headers, as=0D defined in [LISP]. In this document, the term refers to any=0D device implementing ITR functionality, including a Proxy-ITR (see=0D= [LISP-IW]). Under some circumstances, a LISP Map Resolver may=0D also originate Map-Requests (see [LISP-MS]).=0D =0D Egress Tunnel Router (ETR): A router which sends LISP Map-Replies=0D= in response to LISP Map-Requests and decapsulates LISP-=0D encapsulated IP datagrams for delivery to end systems, as defined=0D= in [LISP]. In this document, the term refers to any device=0D implementing ETR functionality, including a Proxy-ETR (see=0D [LISP-IW]). Under some circumstances, a LISP Map Server may also=0D= respond to Map-Requests (see [LISP-MS]).=0D =0D Routing Locator (RLOC): A routable IP address for a LISP tunnel=0D router (ITR or ETR). Interchangeably referred to as a "locator"=0D= in this document. An RLOC is also the output of a EID-to-RLOC=0D mapping lookup; an EID-prefix maps to one or more RLOCs.=0D Typically, RLOCs are numbered from topologically-aggregatable=0D blocks that are assigned to a site at each point where it attaches=0D= to the global Internet; where the topology is defined by the=0D connectivity of provider networks, RLOCs can be thought of as=0D Provider Aggregatable (PA) addresses. Routing for RLOCs is not=0D carried on the ALT.=0D =0D EID-to-RLOC Mapping: A binding between an EID-prefix and the set of=0D= RLOCs that can be used to reach it; sometimes referred to simply=0D= as a "mapping".=0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 6]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D EID-prefix Reachability: An EID-prefix is said to be "reachable" if=0D= one or more of its locators are reachable. That is, an EID-prefix=0D= is reachable if the ETR that is authoritative for a given EID-to-=0D= RLOC mapping is reachable.=0D =0D Default Mapping: A Default Mapping is a mapping entry for EID-=0D prefix 0.0.0.0/0 (0::/0 for ipv6). It maps to a locator-set used=0D= for all EIDs in the Internet. If there is a more specific EID-=0D prefix in the mapping cache it overrides the Default Mapping=0D entry. The Default Mapping can be learned by configuration or=0D from a Map-Reply message.=0D =0D ALT Default Route: A EID-prefix value of 0.0.0.0/0 (or 0::/0 for=0D ipv6) which may be learned from the ALT or statically configured=0D= on an edge ALT Router. The ALT-Default Route defines a forwarding=0D= path for a packet to be sent into the ALT on a router which does=0D= not have a full ALT forwarding database.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 7]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 3. The LISP+ALT model=0D =0D The LISP+ALT model uses the same basic query/response protocol that=0D= is documented in [LISP]. In particular, LISP+ALT provides two types=0D= packet that an ITR can originate to obtain EID-to-RLOC mappings:=0D =0D Map-Request: A Map-Request message is sent into the ALT to request=0D= an EID-to-RLOC mapping. The ETR which owns the mapping will=0D respond to the ITR with a Map-Reply message. Since the ALT only=0D= forwards on EID destinations, the destination address of the Map-=0D= Request sent on the ALT must be an EID. See [LISP] for the format=0D= of Map-Request and Map-Reply packets.=0D =0D Data Probe: Alternatively, an ITR may encapsulate and send the first=0D= data packet destined for a EID with no known RLOCs into the ALT as=0D= a Data Probe. This might be done minimize packet loss and to=0D probe for the mapping. As above, the authoritative ETR for the=0D EID-prefix will respond to the ITR with a Map-Reply message when=0D= it receives the data packet over the ALT. As a side-effect, the=0D= encapsulated data packet is delivered to the end-system at the ETR=0D= site. Note that the Data Probe inner IP destination address,=0D which is an EID, is copied to the outer IP destination address so=0D= that the resulting packet can be routed over the ALT. See=0D Section 3.3 for caveats on the usability of Data Probes.=0D =0D The term "ALT Datagram" is short-hand for a Map-Request or Data Probe=0D= to be sent into or forwarded on the ALT. Note that while the outer=0D= header Source Address of an ALT Datagram is currently expected to be=0D= an RLOC, there may be situations (i.e. for experimentation with=0D caching in intermediate ALT nodes) where an EID would be used to=0D force a Map-Reply to be routed back through the ALT.=0D =0D 3.1. Routeability of EIDs=0D =0D A LISP EID has the same syntax as IP address and can be used,=0D unaltered, as the source or destination of an IP datagram. In=0D general, though, EIDs are not routable on the public Internet; LISP+=0D= ALT provides a separate, virtual network, known as the LISP=0D Alternative Logical Topology (ALT) on which a datagram using an EID=0D= as an IP destination address may be transmitted. This network is=0D built as an overlay on the public Internet using tunnels to=0D interconnect ALT Routers. BGP runs over these tunnels to propagate=0D= path information needed to forward ALT Datagrams. Importantly, while=0D= the ETRs are the source(s) of the unaggregated EID-prefixes, LISP+ALT=0D= uses existing BGP mechanisms to aggregate this information.=0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 8]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 3.1.1. Mechanisms for an ETR to originate EID-prefixes=0D =0D There are three ways that an ETR may originate its mappings into the=0D= ALT:=0D =0D 1. By registration with a Map Server as documented in [LISP-MS].=0D This is the common case and is expected to be used by the=0D majority of ETRs.=0D =0D 2. Using a "static route" on the ALT. Where no Map-Server is=0D available, an edge ALT Router may be configured with a "static=0D EID-prefix route" pointing to an ETR.=0D =0D 3. Edge connection to the ALT. If a site requires fine- grained=0D control over how its EID-prefixes are advertised in to the ALT,=0D= it may configure its ETR(s) with tunnel and BGP connections to=0D edge ALT Routers.=0D =0D 3.1.2. Mechanisms for an ITR to forward to EID-prefixes=0D =0D There are three ways that an ITR may send ALT Datagrams:=0D =0D 1. Through a Map Resolver as documented in [LISP-MS]. This is the=0D= common case and is expected to be used by the majority of ITRs.=0D= =0D 2. Using a "default route". Where a Map Resolver is not available,=0D= an ITR may be configured with a static ALT Default Route pointing=0D= to an edge ALT Router.=0D =0D 3. Edge connection to the ALT. If a site requires fine-grained=0D knowledge of what prefixes exist on the ALT, it may configure its=0D= ITR(s) with tunnel and BGP connections to edge ALT Routers.=0D =0D 3.1.3. Map Server Model preferred=0D =0D The ALT-connected ITR and ETR cases are expected to be rare, as the=0D= Map Server/Map Resolver model is both simpler for an ITR/ETR operator=0D= to use, and provides a more general service interface to not only the=0D= ALT, but also to other mapping databases that may be developed in the=0D= future.=0D =0D 3.2. Connectivity to non-LISP sites=0D =0D As stated above, EIDs used as IP addresses by LISP sites are not=0D routable on the public Internet. This implies that, absent a=0D mechanism for communication between LISP and non-LISP sites,=0D connectivity between them is not possible. To resolve this problem,=0D= an "interworking" technology has been defined; see [LISP-IW] for=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 9]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D details.=0D =0D 3.3. Caveats on the use of Data Probes=0D =0D It is worth noting that there has been a great deal of discussion and=0D= controversy about whether Data Probes are a good idea. On the one=0D hand, using them offers a method of avoiding the "first packet drop"=0D= problem when an ITR does not have a mapping for a particular EID-=0D prefix. On the other hand, forwarding data packets on the ALT would=0D= require that it either be engineered to support relatively high=0D traffic rates, which is not generally feasible for a tunneled=0D network, or that it be carefully designed to aggressively rate-limit=0D= traffic to avoid congestion or DoS attacks. There may also be issues=0D= caused by different latency or other performance characteristics=0D between the ALT path taken by an initial Data Probe and the=0D "Internet" path taken by subsequent packets on the same flow once a=0D= mapping is in place on an ITR. For these reasons, the use of Data=0D Probes is not recommended at this time; they should only be=0D originated an ITR when explicitly configured to do so and such=0D configuration should only be enabled when performing experiments=0D intended to test the viability of using Data Probes.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 10]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 4. LISP+ALT: Overview=0D =0D LISP+ALT is a hybrid push/pull architecture. Aggregated EID-prefixes=0D= are advertised among the ALT Routers and to those (rare) ITRs that=0D are directly connected via a tunnel and BGP to the ALT. Specific=0D EID-to-RLOC mappings are requested by an ITR (and returned by an ETR)=0D= using LISP when it sends a request either via a Map Resolver or to an=0D= edge ALT Router.=0D =0D The basic idea embodied in LISP+ALT is to use BGP, running on a=0D tunneled overlay network (the ALT), to establish reachability between=0D= ALT Routers. The ALT BGPRoute Information Base (RIB) is comprised of=0D= EID-prefixes and associated next hops. ALT Routers interconnect=0D using BGP and propagate EID-prefix updates among themselves. EID-=0D prefix information is learned from ETRs at the "edge" of the ALT=0D either through the use of the Map Server interface (the commmon=0D case), static configuration, or by BGP-speaking ETRs.=0D =0D An ITR use the ALT to learn the best path for forwarding an ALT=0D Datagram destined to a particular EID-prefix. An ITR will normally=0D= use a Map Resolver to send its ALT Datagrams on to the ALT but may,=0D= in unusual circumstances, use a static ALT Default Route or connect=0D= to the ALT using BGP.=0D =0D Note that while this document specifies the use of Generic Routing=0D Encapsulation (GRE) as a tunneling mechanism, there is no reason that=0D= parts of the ALT cannot be built using other tunneling technologies,=0D= particularly in cases where GRE does not meet security, management,=0D= or other operational requirements. References to "GRE tunnel" in=0D later sections of this document should therefore not be taken as=0D prohibiting or precluding the use of other tunneling mechanisms.=0D Note also that two ALT Routers that are directly adjacent (with no=0D layer-3 router hops between them) need not use a tunnel between them;=0D= in this case, BGP may be configured across the interfaces that=0D connect to their common subnet and that subnet is then considered to=0D= be part of the ALT topology. Use of techniques such as "eBGP=0D multihop" to connect ALT Routers that do not share a tunnel or common=0D= subnet is not recommended as the non-ALT Routers in between the ALT=0D= Routers in such a configuration may not have information necessary to=0D= forward ALT Datagrams destined to EID-prefixes exchanged across that=0D= BGP session.=0D =0D In summary, LISP+ALT uses BGP to build paths through ALT Routers so=0D= that an ALT Datagram sent in to the ALT can be forwarded to the ETR=0D= that holds the EID-to-RLOC mapping for that EID-prefix. This=0D reachability is carried as IPv4 or ipv6 NLRI without modification=0D (since an EID-prefix has the same syntax as IPv4 or ipv6 address=0D prefix). ALT Routers establish BGP sessions with one another,=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 11]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D forming the ALT. An ALT Router at the "edge" of the topology learns=0D= EID-prefixes originated by authoritative ETRs. Learning may be=0D though the Map Server interface, by static configuration, or via BGP=0D= with the ETRs. An ALT Router may also be configured to aggregate=0D EID-prefixes received from ETRs or from other LISP+ALT routers that=0D= are topologically "downstream" from it.=0D =0D 4.1. ITR traffic handling=0D =0D When an ITR receives a packet originated by an end system withind its=0D= site (i.e. a host for which the ITR is the exit path out of the site)=0D= and the destination EID for that packet is not known in the ITR's=0D mapping cache, the ITR creates either a Map-Request for the=0D destination EID or the original packet encapsulated as a Data Probe=0D= (see Section 3.3 for caveats on the usability of Data Probes). The=0D= result, known as an ALT Datagram, is then sent to an ALT Router (see=0D= also [LISP-MS] for non-ALT-connected ITRs, noting that Data Probes=0D cannot be sent to a Map-Resolver). This "first hop" ALT Router uses=0D= EID-prefix routing information learned from other ALT Routers via BGP=0D= to guide the packet to the ETR which "owns" the prefix. Upon receipt=0D= by the ETR, normal LISP processing occurs: the ETR responds to the=0D ITR with a LISP Map-Reply that lists the RLOCs (and, thus, the ETRs=0D= to use) for the EID-prefix. For Data Probes, the ETR also=0D decapsulates the packet and transmits it toward its destination.=0D =0D Upon receipt of the Map-Reply, the ITR installs the RLOC information=0D= for a given prefix into a local mapping database. With these mapping=0D= entries stored, additional packets destined to the given EID-prefix=0D= are routed directly to an RLOC without use of the ALT, until either=0D= the entry's TTL has expired, or the ITR can otherwise find no=0D reachable ETR. Note that a current mapping may exist that contains=0D= no reachable RLOCs; this is known as a Negative Cache Entry and it=0D indicates that packets destined to the EID-prefix are to be dropped.=0D= =0D Full details on Map-Request/Map-Reply processing may be found in=0D [LISP].=0D =0D Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.=0D= Map-Requests and Data Probes (if supported). Given the relatively=0D low performance expected of a tuneled topology, ALT Routers (and Map=0D= Resolvers) should aggressively rate-limit the ingress of ALT=0D Datagrams from ITRs and, if possible, should be configured to not=0D accept packets that are not ALT Datagrams.=0D =0D 4.2. EID Assignment - Hierarchy and Topology=0D =0D EID-prefixes are expected to be allocated to a LISP site by Internet=0D= Registries. Where a site has multiple aggregations which are aligned=0D= =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 12]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D on a power-of-2 block boundary, they should be aggregated into a=0D single EID-prefix for advertisement. The ALT network is built in a=0D= roughly hierarchical, partial mesh which is intended to allow=0D aggregation where clearly-defined hierarchical boundaries exist.=0D Building such a structure should minimize the number of EID-prefixes=0D= carried by LISP+ALT nodes near the top of the hierarchy.=0D =0D Routes on the ALT do not need to respond to changes in policy,=0D subscription, or underlying physical connectivity, so the topology=0D can remain relatively static and aggregation can be sustained.=0D Because routing on the ALT uses BGP, the same rules apply for=0D generating aggregates; in particular, a ALT Router should only be=0D configured to generate an aggregate if it is configured with BGP=0D sessions to all of the originators of components (more-specifics=0D prefixes) of that aggregate. Not all of the components of need to be=0D= present for the aggregate to be originated (some may be holes in the=0D= covering prefix and some may be down) but the aggregating router must=0D= be configured to learn the state of all of the components.=0D =0D Under what circumstances the ALT Router actually generates the=0D aggregate is a matter of local policy: in some cases, it will be=0D statically configured to do so at all times with a "static discard"=0D= route. In other cases, it may be configured to only generate the=0D aggregate prefix if at least one of the components of the aggregate=0D= is learned via BGP.=0D =0D An ALT Router must not genearte an aggregate that includes a non-=0D LISP-speaking hole unless it can be configured to return a Negative=0D= Map-Reply with action=3D"Natively-Forward" (see [LISP]) if it = receives=0D an ALT Datagram that matches that hole. If it receives an ALT=0D Datagram that matches a LISP-speaking hole that is currently not=0D reachable, it should return a Negative Map-Reply with action=3D"drop".=0D= Negative Map-Replies should be returned with a short TTL, as=0D specified in [LISP-MS]. Note that an off-the-shelf, non-LISP-=0D speaking router configured as an aggregating ALT Router cannot send=0D= Negative Map-Replies, so such a router must never originate an=0D aggregate that includes a non-LISP-speaking hole.=0D =0D This implies that two ALT Routers that share an overlapping set of=0D prefixes must exchange those prefixes if either is to generate and=0D export a covering aggregate for those prefixes. It also implies that=0D= an ETR which connects to the ALT using BGP must maintain BGP sessions=0D= with all of the ALT Routers that are configured to originate an=0D aggregate which covers that prefix and that each of those ALT Routers=0D= must be explicitly configured to know the set of EID-prefixes that=0D make up any aggregate that it originates. See also [LISP-MS] for an=0D= example of other ways that prefix origin consistency and aggregation=0D= are maintained.=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 13]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D As an example, consider ETRs that are originating EID-prefixes for=0D 10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and 10.1.192.0/24. An ALT=0D= Router should only be configured to generate an aggregate for=0D 10.1.0.0/16 if it has BGP sessions configured with all of these ETRs,=0D= in other words, only if it has sufficient knowledge about the state=0D= of those prefixes to summarize them. If the Router originating=0D 10.1.0.0/16 receives an ALT Datagram destined for 10.1.77.88, a non-=0D= LISP destination covered by the aggregate, it returns a Negative Map-=0D= Reply with action "Natively-Forward". If it receives an ALT Datagram=0D= destined for 10.1.128.199 but the configured LISP prefix=0D 10.1.128.0/24 is unreachable, it returns a Negative Map-Reply with=0D action "drop".=0D =0D Note: much is currently uncertain about the best way to build the ALT=0D= network; as testing and prototype deployment proceeds, a guide to how=0D= to best build the ALT network will be developed.=0D =0D 4.3. Use of GRE and BGP between LISP+ALT Routers=0D =0D The ALT network is built using GRE tunnels between ALT Routers. BGP=0D= sessions are configured over those tunnels, with each ALT Router=0D acting as a separate AS "hop" in a Path Vector for BGP. For the=0D purposes of LISP+ALT, the AS-path is used solely as a shortest-path=0D= determination and loop-avoidance mechanism. Because all next-hops=0D are on tunnel interfaces, no IGP is required to resolve those next-=0D= hops to exit interfaces.=0D =0D LISP+ALT's use of GRE and BGP facilities deployment and operation of=0D= LISP because no new protocols need to be defined, implemented, or=0D used on the overlay topology; existing BGP/GRE tools and operational=0D= expertise are also re-used. Tunnel address assignment is also easy:=0D= since the addresses on an ALT tunnel are only used by the pair of=0D routers connected to the tunnel, the only requirement of the IP=0D addresses used to establish that tunnel is that the attached routers=0D= be reachable by each other; any addressing plan, including private=0D addressing, can therefore be used for ALT tunnels.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 14]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 5. EID-prefix Propagation and Map-Request Forwarding=0D =0D As described in Section 8.2, an ITR sends an ALT Datagram to a given=0D= EID-to-RLOC mapping. The ALT provides the infrastructure that allows=0D= these requests to reach the authoritative ETR.=0D =0D Note that under normal circumstances Map-Replies are not sent over=0D the ALT - an ETR sends a Map-Reply to the source RLOC learned from=0D the original Map-Request. There may be scenarios, perhaps to=0D encourage caching of EID-to-RLOC mappings by ALT Routers, where Map-=0D= Replies could be sent over the ALT or where a "first-hop" ALT router=0D= might modify the originating RLOC on a Map-Request received from an=0D= ITR to force the Map-Reply to be returned to the "first-hop" ALT=0D Router. These cases will not be supported by initial LISP+ALT=0D implementations but may be subject to future experimentation.=0D =0D ALT Routers propagate path information via BGP ([RFC4271]) that is=0D used by ITRs to send ALT Datagrams toward the appropriate ETR for=0D each EID-prefix. BGP is run on the inter-ALT Router links, and=0D possibly between an edge ("last hop") ALT Router and an ETR or=0D between an edge ("first hop") ALT Router and an ITR. The ALT BGP RIB=0D= consists of aggregated EID-prefixes and their next hops toward the=0D authoritative ETR for that EID-prefix.=0D =0D 5.1. Changes to ITR behavior with LISP+ALT=0D =0D As previously described, an ITR will usually use the Map Resolver=0D interface and will send its Map Requests to a Map Resolver. When an=0D= ITR instead connects via tunnels and BGP to the ALT, it sends ALT=0D Datagrams to one of its "upstream" ALT Routers; these are sent only=0D= to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh=0D= Map-Requests are not sent on the ALT. As in basic LISP, it should=0D use one of its RLOCs as the source address of these queries; it=0D should not use a tunnel interface as the source address as doing so=0D= will cause replies to be forwarded over the tunneled topology and may=0D= be problematic if the tunnel interface address is not routed=0D throughout the ALT. If the ITR is running BGP with the LISP+ALT=0D router(s), it selects the appropriate ALT Router based on the BGP=0D information received. If it is not running BGP, it uses a=0D statically-configued ALT Default Route to select an ALT Router.=0D =0D 5.2. Changes to ETR behavior with LISP+ALT=0D =0D As previously described, an ETR will usually use the Map Server=0D interface (see [LISP-MS]) and will register its EID-prefixes with its=0D= configured Map Servers. When an ETR instead connects using BGP to=0D one or more ALT Routers, it announces its EID-prefix(es) to those ALT=0D= Routers. Note that when an ETR generates a Map-Reply message to=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 15]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D return to a querying ITR, it sends it to the ITR's source-RLOC (i.e.,=0D= on the underlying Internet topology, not on the ALT; this avoids any=0D= latency penalty (or "stretch") that might be incurred by routing over=0D= the ALT).=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 16]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 6. BGP configuration and protocol considerations=0D =0D 6.1. Autonomous System Numbers (ASNs) in LISP+ALT=0D =0D The primary use of BGP today is to define the global Internet routing=0D= topology in terms of its participants, known as Autonomous Systems.=0D= LISP+ALT specifies the use of BGP to create a global overlay network=0D= (the ALT) for finding EID-to-RLOC mappings. While related to the=0D global routing database, the ALT serves a very different purpose and=0D= is organized into a very different hierarchy. Because LISP+ALT does=0D= use BGP, however, it uses ASNs in the paths that are propagated among=0D= ALT Routers. To avoid confusion, it needs to be stressed that that=0D= these LISP+ALT ASNs use a new numbering space that is unrelated to=0D the ASNs used by the global routing system. Exactly how this new=0D space will be assigned and managed will be determined during the=0D deployment of LISP+ALT.=0D =0D Note that the ALT Routers that make up the "core" of the ALT will not=0D= be associated with any existing core-Internet ASN because the ALT=0D topology is completely separate from, and independent of, the global=0D= Internet routing system.=0D =0D 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT=0D =0D As defined by this document, LISP+ALT may be implemented using BGP=0D without modification. Given the fundamental operational difference=0D= between propagating global Internet routing information (the current=0D= dominant use of BGP) and creating an overlay network for finding EID-=0D= to-RLOC mappings (the use of BGP proposed by this document), it may=0D= be desirable to assign a new SAFI [RFC2858] to prevent operational=0D confusion and difficulties, including the inadvertent leaking of=0D information from one domain to the other. Use of a separate SAFI=0D would make it easier to debug many operational problems but would=0D come at a significant cost: unmodified, off-the-shelf routers which=0D= do not understand the new SAFI could not be used to build any part of=0D= the ALT network. At present, this document does not request the=0D assignment of a new SAFI; additional experimentation may suggest the=0D= need for one in the future.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 17]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 7. EID-prefix Aggregation=0D =0D The ALT BGP peering topology should be arranged in a tree-like=0D fashion (with some meshiness), with redundancy to deal with node and=0D= link failures. A basic assumption is that as long as the routers are=0D= up and running, the underlying Internet will provide alternative=0D routes to maintain BGP connectivity among ALT Routers.=0D =0D Note that, as mentioned in Section 4.2, the use of BGP by LISP+ALT=0D requires that information only be aggregated where all active more-=0D= specific prefixes of a generated aggregate prefix are known. This is=0D= no different than the way that BGP route aggregation works in the=0D existing global routing system: a service provider only generates an=0D= aggregate route if it is configured to learn to all prefixes that=0D make up that aggregate.=0D =0D 7.1. Stability of the ALT=0D =0D It is worth noting that LISP+ALT does not directly propagate EID-to-=0D= RLOC mappings. What it does is provide a mechanism for an ITR to=0D commonicate with the ETR that holds the mapping for a particular EID-=0D= prefix. This distinction is important when considering the stability=0D= of BGP on the ALT network as compared to the global routing system.=0D= It also has implications for how site-specific EID-prefix information=0D= may be used by LISP but not propagated by LISP+ALT (see Section 7.2=0D= below).=0D =0D RLOC prefixes are not propagated through the ALT so their=0D reachability is not determined through use of LISP+ALT. Instead,=0D reachability of RLOCs is learned through the LISP ITR-ETR exchange.=0D= This means that link failures or other service disruptions that may=0D= cause the reachability of an RLOC to change are not known to the ALT.=0D= Changes to the presence of an EID-prefix on the ALT occur much less=0D= frequently: only at subscription time or in the event of a failure of=0D= the ALT infrastructure itself. This means that "flapping" (frequent=0D= BGP updates and withdrawals due to prefix state changes) is not=0D likely and mapping information cannot become "stale" due to slow=0D propagation through the ALT BGP mesh.=0D =0D 7.2. Traffic engineering using LISP=0D =0D Since an ITR learns an EID-to-RLOC mapping directly from the ETR that=0D= owns it, it is possible to perform site-to-site traffic engineering=0D= by setting the preference and/or weight fields, and by including=0D more-specific EID-to-RLOC information in Map-Reply messages.=0D =0D This is a powerful mechanism that can conceivably replace the=0D traditional practice of routing prefix deaggregation for traffic=0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 18]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D engineering purposes. Rather than propagating more-specific=0D information into the global routing system for local- or regional-=0D optimization of traffic flows, such more-specific information can be=0D= exchanged, through LISP (not LISP+ALT), on an as-needed basis between=0D= only those ITRs/ETRs (and, thus, site pairs) that need it. Should a=0D= receiving ITR decide that it does not wish to store such more-=0D specific information, it has the option of discarding it as long as a=0D= shorter, covering EID-prefix exists. Such an exchange of "more-=0D specifics" between sites facilitates traffic engineering, by allowing=0D= richer and more fine-grained policies to be applied without=0D advertising additional prefixes into either the ALT or the global=0D routing system.=0D =0D Note that these new traffic engineering capabilities are an attribute=0D= of LISP and are not specific to LISP+ALT; discussion is included here=0D= because the BGP-based global routing system has traditionally used=0D propagation of more-specific routes as a crude form of traffic=0D engineering.=0D =0D 7.3. Edge aggregation and dampening=0D =0D Normal BGP best common practices apply to the ALT network. In=0D particular, first-hop ALT Routers will aggregate EID prefixes and=0D dampen changes to them in the face of excessive updates. Since EID-=0D= prefix assignments are not expected to change as frequently as global=0D= routing BGP prefix reachability, such dampening should be very rare,=0D= and might be worthy of logging as an exceptional event. It is again=0D= worth noting that the ALT carries only EID-prefixes, used to=0D construct BGP paths to their owning ETRs; it does not carry=0D reachability about RLOCs. In addition, EID-prefix information may be=0D= aggregated as the topology and address assignment hierarchy allow.=0D Since the topology is all tunneled and can be modified as needed,=0D reasonably good aggregation should be possible. In addition, since=0D= most ETRs are expected to connect to the ALT using the Map Server=0D interface, Map Servers will implement a natural "edge" for the ALT=0D where dampening and aggregation can be applied. For these reasons,=0D= the set of prefix information on the ALT can be expected to be both=0D= better aggregated and considerably less volatile than the actual EID-=0D= to-RLOC mappings.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 19]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 8. Connecting sites to the ALT network=0D =0D 8.1. ETRs originating information into the ALT=0D =0D EID-prefix information is originated into the ALT by three different=0D= mechanisms:=0D =0D Map Server: In most cases, a site will configure its ETR(s) to=0D register with one or more Map Servers (see [LISP-MS]), and does=0D not participate directly in the ALT.=0D =0D BGP: For a site requiring complex control over their EID-prefix=0D origination into the ALT, an ETR may connect to the LISP+ALT=0D overlay network by running BGP to one or more ALT Router(s) over=0D= tunnel(s). The ETR advertises reachability for its EID-prefixes=0D= over these BGP connection(s). The edge ALT Router(s) that=0D receive(s) these prefixes then propagate(s) them into the ALT.=0D Here the ETR is simply an BGP peer of ALT Router(s) at the edge of=0D= the ALT. Where possible, an ALT Router that receives EID-prefixes=0D= from an ETR via BGP should aggregate that information.=0D =0D Configuration: One or more ALT Router(s) may be configured to=0D originate an EID-prefix on behalf of the non-BGP-speaking ETR that=0D= is authoritative for a prefix. As in the case above, the ETR is=0D= connected to ALT Router(s) using GRE tunnel(s) but rather than BGP=0D= being used, the ALT Router(s) are configured with what are in=0D effect "static routes" for the EID-prefixes "owned" by the ETR.=0D The GRE tunnel is used to route Map-Requests to the ETR.=0D =0D Note: in all cases, an ETR may register to multiple Map Servers or=0D= connect to multiple ALT Routers for the following reasons:=0D =0D * redundancy, so that a particular ETR is still reachable even if=0D= one path or tunnel is unavailable.=0D =0D * to connect to different parts of the ALT hierarchy if the ETR=0D= "owns" multiple EID-to-RLOC mappings for EID-prefixes that=0D cannot be aggregated by the same ALT Router (i.e. are not=0D topologically "close" to each other in the ALT).=0D =0D 8.2. ITRs Using the ALT=0D =0D In the common configuration, an ITR does not need to know anything=0D about the ALT, since it sends Map-Requests to one of its configured=0D= Map-Resolvers (see [LISP-MS]). There are two exceptional cases:=0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 20]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D Static default: If a Map Resolver is not available but an ITR is=0D adjacent to an ALT Router (either over a common subnet or through=0D= the use of a tunnel), it can use an ALT Default Route route to=0D cause all ALT Datagrams to be sent that ALT Router. This case is=0D= expected to be rare.=0D =0D Connection to ALT: A site with complex Internet connectivity needs=0D= may need more fine-grained distinction between traffic to LISP-=0D capable and non-LISP-capable sites. Such a site may configure=0D each of its ITRs to connect directly to the ALT, using a tunnel=0D and BGP connection. In this case, the ITR will receive EID-prefix=0D= routes from its BGP connection to the ALT Router and will LISP-=0D encapsulate and send ALT Datagrams through the tunnel to the ALT=0D= Router. Traffic to other destinations may be forwarded (without=0D= LISP encapsulation) to non-LISP next-hop routers that the ITR=0D knows.=0D =0D In general, an ITR that connects to the ALT does so only to to ALT=0D= Routers at the "edge" of the ALT (typically two for redundancy).=0D= There may, though, be situations where an ITR would connect to=0D other ALT Routers to receive additional, shorter path information=0D= about a portion of the ALT of interest to it. This can be=0D accomplished by establishing GRE tunnels between the ITR and the=0D= set of ALT Routers with the additional information. This is a=0D purely local policy issue between the ITR and the ALT Routers in=0D= question.=0D =0D As described in [LISP-MS], Map-Resolvers do not accept or forward=0D Data Probes; in the rare scenario that an ITR does support and=0D originate Data Probes, it must do so using one of the exceptional=0D configurations described above. Note that the use of Data Probes is=0D= discouraged at this time (see Section 3.3).=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 21]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 9. IANA Considerations=0D =0D This document makes no request of the IANA.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 22]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 10. Security Considerations=0D =0D LISP+ALT shares many of the security characteristics of BGP. Its=0D security mechanisms are comprised of existing technologies in wide=0D operational use today, so securing the ALT should be mostly a matter=0D= of applying the same technology that is used to secure the BGP-based=0D= global routing system (see Section 10.3 below).=0D =0D 10.1. Apparent LISP+ALT Vulnerabilities=0D =0D This section briefly lists the known potential vulnerabilities of=0D LISP+ALT.=0D =0D Mapping Integrity: Can an attacker insert bogus mappings to black-=0D= hole (create Denial-of-Service, or DoS attack) or intercept LISP=0D= data-plane packets?=0D =0D ALT Router Availability: Can an attacker DoS the ALT Routers=0D connected to a given ETR? If a site's ETR cannot advertise its=0D EID-to-RLOC mappings, the site is essentially unavailable.=0D =0D ITR Mapping/Resources: Can an attacker force an ITR or ALT Router to=0D= drop legitimate mapping requests by flooding it with random=0D destinations for which it will generate large numbers of Map-=0D Reqeusts and fill its mapping cache? Further study is required to=0D= see the impact of admission control on the overlay network.=0D =0D EID Map-Request Exploits for Reconnaissance: Can an attacker learn=0D= about a LISP site's TE policy by sending legitimate mapping=0D requests and then observing the RLOC mapping replies? Is this=0D information useful in attacking or subverting peer relationships?=0D= Note that any public LISP mapping database will have similar data-=0D= plane reconnaissance issue.=0D =0D Scaling of ALT Router Resources: Paths through the ALT may be of=0D lesser bandwidth than more "direct" paths; this may make them more=0D= prone to high-volume denial-of-service attacks. For this reason,=0D= all components of the ALT (ETRs and ALT Routers) should be=0D prepared to rate-limit traffic (ALT Datagrams) that could be=0D received across the ALT.=0D =0D UDP Map-Reply from ETR: Since Map-Replies are sent directly from the=0D= ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various=0D= types of DoS attacks (this is a general property of LISP, not an=0D= LISP+ALT vulnerability).=0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 23]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D More-specific prefix leakage: Because EID-prefixes on the ALT are=0D expected to be fairly well-aggregated and EID-prefixes propagated=0D= out to the global Internet (see [LISP-IW] much more so, accidental=0D= leaking or malicious advertisement of an EID-prefix into the=0D global routing system could cause traffic redirection away from a=0D= LISP site. This is not really a new problem, though, and its=0D solution can only be achieved by much more strict prefix filtering=0D= and authentication on the global routing system.=0D =0D 10.2. Survey of LISP+ALT Security Mechanisms=0D =0D Explicit peering: The devices themselves can both prioritize=0D incoming packets, as well as potentially do key checks in hardware=0D= to protect the control plane.=0D =0D Use of TCP to connect elements: This makes it difficult for third=0D parties to inject packets.=0D =0D Use of HMAC Protected BGP/TCP Connections: HMAC is used to verify=0D message integrity and authenticity, making it nearly impossible=0D for third party devices to either insert or modify messages.=0D =0D Message Sequence Numbers and Nonce Values in Messages: This allows=0D= an ITR to verify that the Map-Reply from an ETR is in response to=0D= a Map-Request originated by that ITR (this is a general property=0D= of LISP; LISP+ALT does not change this behavior).=0D =0D 10.3. Use of new IETF standard BGP Security mechanisms=0D =0D LISP+ALT's use of BGP allows the ALT to take advantage of BGP=0D security features designed for existing Internet BGP use.=0D =0D For example, should either S-BGP [I-D.murphy-bgp-secr] or soBGP=0D [I-D.white-sobgparchitecture] become widely deployed it expected that=0D= LISP+ALT could use these mechanisms to provide authentication of EID-=0D= to-RLOC mappings, and EID origination.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 24]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 11. Acknowledgments=0D =0D The authors would like to specially thank J. Noel Chiappa who was a=0D= key contributer to the design of the LISP-CONS mapping database (many=0D= ideas from which made their way into LISP+ALT) and who has continued=0D= to provide invaluable insight as the LISP effort has evolved. Others=0D= who have provided valuable contributions include John Zwiebel, Hannu=0D= Flinck, Amit Jain, John Scudder, and Scott Brim.=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 25]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D 12. References=0D =0D 12.1. Normative References=0D =0D [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,=0D "Locator/ID Separation Protocol (LISP)",=0D draft-ietf-lisp-06.txt (work in progress), January 2010.=0D= =0D [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",=0D draft-ietf-lisp-ms-04.txt (work in progress),=0D October 2009.=0D =0D [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.=0D Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,=0D= March 2000.=0D =0D [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,=0D "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.=0D= =0D [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway=0D Protocol 4 (BGP-4)", RFC 4271, January 2006.=0D =0D [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing=0D (CIDR): The Internet Address Assignment and Aggregation=0D Plan", BCP 122, RFC 4632, August 2006.=0D =0D 12.2. Informative References=0D =0D [I-D.murphy-bgp-secr]=0D Murphy, S., "BGP Security Analysis",=0D draft-murphy-bgp-secr-04 (work in progress),=0D November 2001.=0D =0D [I-D.white-sobgparchitecture]=0D White, R., "Architecture and Deployment Considerations for=0D= Secure Origin BGP (soBGP)",=0D draft-white-sobgparchitecture-00 (work in progress),=0D May 2004.=0D =0D [LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,=0D "Interworking LISP with IPv4 and ipv6",=0D draft-ietf-lisp-interworking-02.txt (work in progress),=0D February 2010.=0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 26]=0D= =0C=0D Internet-Draft LISP Alternative Topology (LISP+ALT) March 2010=0D= =0D =0D Authors' Addresses=0D =0D Vince Fuller=0D Cisco=0D Tasman Drive=0D San Jose, CA 95134=0D USA=0D =0D Email: vaf@cisco.com=0D =0D =0D Dino Farinacci=0D Cisco=0D Tasman Drive=0D San Jose, CA 95134=0D USA=0D =0D Email: dino@cisco.com=0D =0D =0D Dave Meyer=0D Cisco=0D Tasman Drive=0D San Jose, CA 95134=0D USA=0D =0D Email: dmm@cisco.com=0D =0D =0D Darrel Lewis=0D Cisco=0D Tasman Drive=0D San Jose, CA 95134=0D USA=0D =0D Email: darlewis@cisco.com=0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D =0D Fuller, et al. Expires September 9, 2010 [Page 27]=0D= =0C=0D =0D --Apple-Mail-15-1057297310 Content-Disposition: attachment; filename="rfcdiff-alt-02-to-03.html" Content-Type: text/html; name="rfcdiff-alt-02-to-03.html" Content-Transfer-Encoding: quoted-printable =0D =0D wdiff draft-fuller-lisp-alt-02.txt = draft-ietf-lisp-alt-03.txt=0D 
=0D
Network Working Group                                       =
D. Farinacci=0D
Internet-Draft                                          =
V. Fuller=0D
Internet-Draft                             =
                 D. Farinacci=0D
Intended status: Experimental                                   D. Meyer=0D=

Expires: October 25, 2008 =
September 9, 2010                          =
            D. Lewis=0D
                                                                   Cisco=0D=

                                                          April 23, 2008=0D
                                                           March 8, 2010=0D
=0D
                  LISP Alternative Topology (LISP+ALT)=0D
                      draft-fuller-lisp-alt-02.txt=0D
                       draft-ietf-lisp-alt-03.txt=0D
=0D
Abstract=0D
=0D
   This document describes a simple mapping database to be used by the=0D=

   Locator/ID Separation Protocol (LISP) to find Endpoint Identifier=0D
   (EID) to Routing Locator (RLOC) mappings.  Termed the Alternative=0D
   Logical Topology (ALT), the database is built as an overlay network=0D=

   on the public Internet using the Border Gateway Protocol (BGP) and=0D
   the Generic Routing Encapsulation (GRE).  Using these proven=0D
   protocols, the ALT can be built and deployed relatively quickly=0D
   without major changes to the existing routing =
infrastructure.=0D
=0D
Status of this Memo=0D
=0D
   By submitting this Internet-Draft, each =
author represents that any=0D
   applicable patent or other IPR claims of which he or =
she=0D
=0D
   This Internet-Draft is =
aware=0D
   have been or will be disclosed, and any of which he or she becomes=0D
   aware will be disclosed, submitted to IETF in accordance full conformance with Section 6 the=0D=

   provisions of BCP 78 =
and BCP 79.=0D
=0D
   Internet-Drafts are working documents of the Internet Engineering=0D
   Task Force (IETF), its areas, and its working groups.  Note that=0D
   other groups may also distribute working documents as Internet-=0D
   Drafts.=0D
=0D
   Internet-Drafts are draft documents valid for a maximum of six months=0D=

   and may be updated, replaced, or obsoleted by other documents at any=0D=

   time.  It is inappropriate to use Internet-Drafts as reference=0D
   material or to cite them other than as "work in progress."=0D
=0D
   The list of current Internet-Drafts can be accessed at=0D
   http://www.ietf.org/ietf/1id-abstracts.txt.=0D
=0D
   The list of Internet-Draft Shadow Directories can be accessed at=0D
   http://www.ietf.org/shadow.html.=0D
=0D
   This Internet-Draft will expire on October =
25, 2008.=0D
=0D
Abstract=0D
=0D
   This document describes a method of building an alternative, logical=0D=

   topology for managing Endpoint Identifier to Routing Locator mappings=0D=

   using September 9, =
2010.=0D
=0D
Copyright Notice=0D
=0D
   Copyright (c) 2010 IETF Trust and the Locator/ID Separation Protocol.  The logical network is=0D
   built persons =
identified as an overlay on =
the public Internet using existing=0D
   technologies and tools, specifically the =
Border Gateway Protocol=0D
   document authors.  All rights reserved.=0D=

=0D
   This document is subject to BCP 78 and the =
Generic Routing Encapsulation.  An important =
design goal for=0D
   LISP+ALT is IETF =
Trust's Legal=0D
   Provisions Relating to allow for IETF=
 Documents=0D
   (http://trustee.ietf.org/license-info) in effect on =
the relatively easy =
deployment date of an=0D=

   efficient mapping system while minimizing changes=0D
   publication of this document.  Please =
review these documents=0D
   carefully, as they describe your rights and restrictions with =
respect=0D
   to existing=0D
   hardware this document. =
 Code Components extracted from this document must=0D
   include Simplified BSD License text as described in Section 4.e of=0D
   the Trust Legal Provisions and software. are =
provided without warranty as=0D
   described in the BSD License.=0D
=0D
Table of Contents=0D
=0D
   1.  Requirements Notation  . . . . . . . =
. . . . . . . . . . . . .  3=0D
   2.  Introduction . . . . . . . . . . . . . . . . . . =
. . . . . . .  4=0D
   3.=0D
   2.  Definition of Terms =
 . . . . . . . . . . . . . . . . . . . . .  5=0D
   4.=0D
   3.  The LISP 1.5 LISP+ALT model . . . . . . . . . . . . . =
. . . . . . . . .  7=0D
   5.  LISP+ALT: Overview  8=
=0D
     3.1.  Routeability of EIDs . . . . . . . . . . . . =
. . . . . . .  8=0D
       3.1.1.  Mechanisms for an ETR to originate =
EID-prefixes  . . .  8=0D
     5.1.  9=0D
       3.1.2.  Mechanisms for an ITR traffic handling to forward to EID-prefixes . . .  =
9=0D
       3.1.3.  Map Server Model preferred . . . . . . . =
. . . . . . .  9=0D
     3.2.  Connectivity to non-LISP sites . . . . .  =
8=0D
     5.2.  EID Assignment - Hierarchy and Topology . . . =
. . . . . .  9=0D
     5.3.  LISP+ALT Router=0D=

     3.3.  Caveats on the use of Data =
Probes  . . . . . . . . . . . . 10=0D
   4.  LISP+ALT: Overview . . . . . . . . . . . . . =
10=0D
     5.4. . . . . . . . . =
. 11=0D
     4.1.  ITR and ETR in a =
LISP+ALT Environment traffic=
 handling . . . . . . . . . . 10=0D
     5.5.  Use of GRE . . =
. . . . . . . 12=0D
     4.2.  EID Assignment - Hierarchy and BGP between LISP+ALT Routers Topology  . . . . . . . 10=0D
   6.  EID-to-RLOC mapping propagation . . 12=0D
     4.3.  Use of GRE and BGP between LISP+ALT Routers  =
. . . . . . . 14=0D
   5.  EID-prefix Propagation and Map-Request Forwarding =
 . . . . . . 12=0D
     6.1. 15=0D
     5.1.  Changes to ITR behavior with LISP+ALT  . . . =
. . . . . . . 12=0D
     6.2. 15=0D
     5.2.  Changes to ETR behavior with LISP+ALT  . . . =
. . . . . . . 12=0D
   7. 15=0D
   6.  BGP configuration and protocol considerations  . =
. . . . . . . 14=0D
     7.1. 17=0D
     6.1.  Autonomous System Numbers (ASNs) in LISP+ALT =
. . . . . . . 14=0D
     7.2. 17=0D
     6.2.  Sub-Address Family Identifier (SAFI) for =
LISP+ALT  . . . . 14=0D
   8.  EID-Prefix 17=0D
   7.  EID-prefix Aggregation . . . . . . . . . . . . . =
. . . . . . . 15=0D
     8.1. 18=0D
     7.1.  Stability of the ALT . . . . . . . . . . . . . . . . . . . 18=0D=

     7.2.  Traffic engineering with using LISP .=
 . . . . . . . . . . . . . 18=0D
     7.3.  Edge aggregation and LISP+ALT dampening . . . . . . . . 15=0D
   9. . . . . . . 19=0D
   8.  Connecting sites to the ALT network  . . . . . . =
. . . . . . . 16=0D
     9.1. 20=0D
     8.1.  ETRs originating information into the ALT  . =
. . . . . . . 16=0D
     9.2. 20=0D
     8.2.  ITRs Receiving =
Information from Using the ALT . . . . . . . . . =
16=0D
   10. . . . . . . . . . . =
. 20=0D
   9.  IANA Considerations  . . . . . . . . . . . . . . =
. . . . . . . 18=0D
   11. 22=0D
   10. Security Considerations  . . . . . . . . . . . . =
. . . . . . . 19=0D
     11.1. 23=0D
     10.1. Apparent LISP+ALT Vulnerabilities  . . . . . =
. . . . . . . 19=0D
     11.2. 23=0D
     10.2. Survey of LISP+ALT Security Mechanisms . . . =
. . . . . . . 20=0D
     11.3. Using existing 24=
=0D
     10.3. Use of new IETF standard BGP Security =
mechanisms . . . . . . . . . . 20=0D
   12. 24=0D
   11. Acknowledgments  . . . . . . . . . . . . . . . . =
. . . . . . . 21=0D
   13. 25=0D
   12. References . . . . . . . . . . . . . . . . . . . =
. . . . . . . 22=0D
     13.1. 26=0D
     12.1. Normative References . . . . . . . . . . . . =
. . . . . . . 22=0D
     13.2. 26=0D
     12.2. Informative References . . . . . . . . . . . =
. . . . . . . 22 =
26=0D
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . =
23=0D
   Intellectual Property and Copyright Statements . . . . . . . . . . =
24 27=0D
=0D
1.  Requirements Notation=0D
=0D
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0D=

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0D=

   document are to be interpreted as described in [RFC2119].=0D
=0D
2.  Introduction=0D
=0D
   This document describes a method of =
building an alternative logical=0D
   topology for managing Endpoint identifier =
the LISP+ALT mapping =
database, to Routing Locator =
mappings be used by=0D
   LISP to find EID-to-RLOC mappings.  The ALT network is =
built using=0D
   the Locator/ID Separation Protocol =
[LISP].  This logical=0D
   topology uses existing technology and tools, specifically =
the Border Gateway Protocol [RFC4271] and its (BGP, [RFC4271]), the BGP multi-protocol=0D=

   extension [RFC2858], along =
with and =
the Generic Routing Encapsulation [RFC2784]=0D=

   protocol (GRE,=0D
   [RFC2784]) to construct an overlay network nnetwork of devices that advertise (ALT Routers)=0D
   which operate on EID-prefixes only.  These Endpoint Identifier Prefix Aggregators hold=0D=

   hierarchically-assigned pieces and use EIDs as forwarding=0D
   destinations.=0D
=0D
   ALT Routers advertise hierarchically-delegated =
segments of the Endpoint =
Identifier space EID=0D
   namespace (i.e., prefixes) and their next hops toward the rest of the ALT; they also=0D
   forward traffic destined for an EID covered by one of those =
prefixes=0D
   toward the network element which is authoritative for Endpoint Identifier-to-Routing Locator =
that EID (i.e.=0D
   is the origin of the advertisement of the EID-to-RLOC =
mapping=0D
   for which=0D
   applies to that prefix. EID). =
 Map Resolvers (MRs; see [LISP-MS]) and, in=0D
   some cases, Ingress Tunnel routers can Routers (ITRs) use this overlay to =
make queries=0D
   against and respond to send=0D
   mapping requests made against the =
distributed=0D
   Endpoint Identifier-to-Routing Locator mapping database.  Note the=0D
   database is distributed (as described in =
(using [LISP]) =
and is stored in =
to the=0D
   ETRs.=0D
=0D
   Note Egress Tunnel =
Routers (ETRs)=0D
   that an important design goal of =
LISP+ALT hold the =
EID-to-RLOC mappings for a particular EID-prefix=0D
=0D
   It is important to minimize note =
that the=0D
   number of changes =
ALT does not distibute actual EID-=0D
   to-RLOC mappings.  What it does provide is a forwarding path from an=0D=

   ITR (or MR) which requires an EID-to-RLOC mapping to =
existing hardware and/or =
software an ETR which=0D
   holds that are=0D
   required mapping.  The =
ITR/MR uses this path to send an ALT=0D
   Datagram (see Section 3) to deploy an =
ETR which then responds with a Map-=0D
   Reply containing the needed mapping system.  It information.=0D
=0D
   One design goal for LISP+ALT is envisioned that in most=0D
   cases to =
use existing technology can =
be used wherever=0D
   possible.  To this end, the ALT is intended to =
be built using off-=0D
   the-shelf routers which already implement =
and deploy LISP+=0D
   ALT.  Since the deployment =
of LISP+ALT adds new required protocols (BGP=0D
   and GRE); little, if any, LISP-specific modifications should be=0D
   needed for such devices to be deployed on the=0D
   network, existing devices not need =
changes or upgrades.  They can=0D
   function as they ALT.  =
Note, though,=0D
   that organizational and operational considerations suggest that ALT=0D=

   Routers be both logically and physically separate from the "native"=0D=

   Internet packet transport system; deploying this overlay on those=0D
   routers which are to =
realize an underlying already participating in the global routing =
system=0D
   and robust physical=0D
   topology. actively =
forwarding Internet traffic is not recommended.=0D
=0D
   The remainder of this document is organized as follows: Section =
3 2=0D
   provides the definitions of terms used in this document.  Section =
4 3=0D
   outlines the basic LISP 1.5 model.  Section 5 4 provides a basic=0D
   overview of the LISP Alternate Topology architecture, and Section =
6 5=0D
   describes how the ALT uses BGP to propagate Endpoint Identifier=0D
   reachability over the overlay network. network and Section 8 6 =
describes other=0D
   considerations for using BGP on the ALT.  Section 7 =
describes the=0D
   construction of the ALT aggregation hierarchy, and Section =
9 8=0D
   discusses how LISP+ALT elements are connected to form the overlay=0D
   network.=0D
=0D
3.=0D
=0D
2.  Definition of Terms=0D
=0D
   LISP+ALT operates on two name spaces and introduces a new network=0D
   element, the LISP+ALT Router (see below).  This section provides=0D
   high-level definitions of the LISP+ALT name spaces, network elements,=0D=

   and message types.=0D
=0D
   The=0D
=0D
    Alternative Logical Topology (ALT):  The virtual overlay network=0D
      made up of tunnels between EID Prefix =
Aggregators. LISP+ALT =
Routers.  The Border Gateway=0D
      Protocol (BGP) runs between LISP+ALT =
routers ALT =
Routers and is used to carry=0D
      reachability information for EID =
prefixes. EID-prefixes.  =
The ALT provides a way=0D
      to forward Map-Requests (and, if supported, Data Probes) toward=0D
      the ETR that "owns" and EID-prefix.  As a tunneled overlay, its=0D
      performance is expected to be quite limited so use of it to=0D
      forward high-bandwidth flows of Data Probes is strongly=0D
      discouraged (see Section 3.3 for additional =
discussion).=0D
=0D
    Legacy Internet:  The portion of the Internet which does not run=0D
      LISP and does not participate in LISP+ALT.=0D
=0D
   LISP+ALT=0D
=0D
    ALT Router:  The =
devices which run on the ALT.  The ALT is a static=0D
      network built using tunnels between LISP+ALT routers. ALT Routers.  These routers=0D
      are deployed in a hierarchy roughly-hierarchical mesh in which =
routers at=0D
      each level in the this =
hierarchy topology are responsible for aggregating =
all=0D
      EID EID-=0D
      prefixes learned from those logically "below" them and advertising=0D=

      summary prefixes to the =
routers those logically "above" them.  =
All prefix  Prefix learning=0D
      and propagation between levels ALT =
Routers is done using BGP.  LISP+ALT routers  An ALT=0D
      Router at the lowest level, or "edge", "edge" of the ALT learn EID ALT, learns EID-=0D
      prefixes either over =
from its "client" ETRs.  See Section 3.1 =
for a BGP session to ETRs or=0D=

      through static routes (in=0D
      description of how EID-prefixes are =
learned at the case "edge" of the "low-opex ETR").=0D
      ALT.  See =
also Section 7 6 for details on how BGP is configured=0D=

      between the different network elements.=0D
=0D
      The primary function of LISP+ALT =
routers is to provide a=0D
      lightweight  When an =
ALT Router=0D
      receives an ALT Datagram, it looks up the destination EID in =
its=0D
      forwarding infrastructure for LISP =
control-plane=0D
      messages (Map-Request and Map-Reply), =
table (composed of EID prefix routes it =
learned from=0D
      neighboring ALT Routers) and forwards it to transport data=0D
      packets when the packet =
has logical next-hop=0D
      on the same =
destination address in both=0D
      the inner (encapsulating) destination and outer destination=0D
      addresses ((i.e., a Data Probe packet). =
overlay network.=0D
=0D
    Endpoint ID (EID):  A 32-bit (for IPv4) or 128-bit (for ipv6) value=0D=

      used in to identify the ultimate source and or destination address fields of the first=0D
      (most inner) LISP header of for a LISP-=0D=

      encapsulated packet.  See [LISP] for details.=0D
=0D
    EID-prefix:  A packet =
that is emitted by=0D
      a system contains set =
of EIDs delegated in its headers and LISP headers a power-of-two block.  EID-=0D
      prefixes are=0D
      prepended only when =
routed on the =
packet reaches an Ingress Tunnel Router=0D
      (ITR) ALT =
(not on the data =
path global Internet) and=0D=

      are expected to the =
destination EID.=0D
=0D
      In LISP+ALT, EID-prefixes MUST BE be assigned in a hierarchical manner =
(in power-of-two) such that=0D=

      they can be aggregated by LISP+ ALT routers.  In addition, Routers.  Such a block is=0D
      characterized by a prefix and a length.  Note that while the ALT=0D
      routing system considers an EID-prefix to be an opaque block of=0D
      EIDs, an end site may have site-local put site-local, topologically-relevant=0D=

      structure in=0D
      how EIDs are topologically organized (subnetting) =
into an EID-prefix for =
routing=0D
      within the site; this structure is not visible to the global=0D
      routing system.=0D
=0D
   EID-Prefix Aggregate: intra-site routing.=0D
=0D
    Aggregated EID-prefixes:  A set of individual EID-prefixes said to be aggregatable that have=0D
      been aggregated in the [RFC4632] sense.  =
That is, an EID-Prefix aggregate is=0D
      defined to be a single contiguous power-of-two EID-prefix block.=0D=

      Such a block is characterized by a prefix and a length.=0D
=0D
   Routing Locator (RLOC):=0D
=0D
    Map Server (MS):   An =
IP address of an egress tunnel router=0D
      (ETR).  It is edge =
ALT Router that provides a registration=0D
      function for non-ALT-connected ETRs, originates EID-prefixes =
into=0D
      the output =
ALT on behalf of =
a EID-to-RLOC mapping lookup.  An EID=0D
      maps those ETRs, and =
forwards Map-Reqeusts to one =
or more RLOCs.  Typically, RLOCs are numbered from=0D
      topologically-aggregatable blocks=0D
      them.  See [LISP-MS] for details.=0D
=0D
    Map Resolver (MR):   An edge ALT Router that =
are assigned to =
accepts an Encapsulated=0D
      Map-Reqeust from a site =
at=0D
      each point to which non-ALT-connected ITR, decapsulates it, and=0D
      forwards it attaches on to the global Internet; where ALT toward the=0D
      topology is defined by =
ETR which owns the =
connectivity of provider networks,=0D
      RLOCs can be thought of as Provider Aggregatable (PA) addresses.=0D=

      Note that in LISP+ALT, RLOCs are not carried =
requested=0D
      EID-prefix.  See [LISP-MS] for details.=0D
=0D
    Ingress Tunnel Router (ITR):   A router which sends LISP Map-=0D
      Requests or encapsulates IP datagrams with LISP headers, as=0D
      defined in [LISP].  In this document, the term refers to any=0D
      device implementing ITR functionality, including a Proxy-ITR (see=0D=

      [LISP-IW]).  Under some circumstances, a LISP Map Resolver may=0D
      also originate Map-Requests (see [LISP-MS]).=0D
=0D
    Egress Tunnel Router (ETR):   A router which sends LISP Map-Replies=0D=

      in response to LISP Map-Requests and decapsulates LISP-=0D
      encapsulated IP datagrams for delivery to end systems, as defined=0D=

      in [LISP].  In this document, the term refers to any device=0D
      implementing ETR functionality, including a Proxy-ETR (see=0D
      [LISP-IW]).  Under some circumstances, a LISP Map Server may also=0D=

      respond to Map-Requests (see [LISP-MS]).=0D
=0D
    Routing Locator (RLOC):  A routable IP address for a LISP tunnel=0D
      router (ITR or ETR).  Interchangeably referred to as a "locator"=0D=

      in this document.  An RLOC is also the output of a EID-to-RLOC=0D
      mapping lookup; an EID-prefix maps to one or more RLOCs.=0D
      Typically, RLOCs are numbered from topologically-aggregatable=0D
      blocks that are assigned to a site at each point where it attaches=0D=

      to the global Internet; where the topology is =
defined by LISP+ALT =
routers. the=0D
      connectivity of provider networks, RLOCs can be thought of as=0D
      Provider Aggregatable (PA) addresses.  Routing for RLOCs is not=0D
      carried on the ALT.=0D
=0D
    EID-to-RLOC Mapping:  A binding between an EID EID-prefix and the RLOC-set set =
of=0D
      RLOCs that can be used to reach the EID.  The term "mapping" refers =
it; sometimes referred to =
an=0D
      EID-to-RLOC mapping.=0D
=0D
    EID Prefix simply=0D
      as a "mapping".=0D
=0D
    EID-prefix Reachability:  An EID prefix EID-prefix is said to be "reachable" if=0D=

      one or more of its locators are reachable.  That is, an =
EID prefix EID-prefix=0D
      is reachable if the ETR (or its =
proxy) that is authoritative for a given EID-to-RLOC EID-to-=0D
      RLOC mapping is reachable.=0D
=0D
    Default Mapping:  A Default Mapping is a mapping entry for EID-=0D
      prefix 0.0.0.0/0. =
0.0.0.0/0 (0::/0 for =
ipv6).  It maps to a locator-set used=0D
      for all EIDs in the Internet.  If there is a more specific =
EID-prefix EID-=0D
      prefix in the mapping cache it overrides the =
Default Mapping=0D
      entry.  The Default Mapping route can be learned by configuration or=0D=

      from a Map-Reply message.=0D
=0D
    ALT Default Route:  A =
Default Route in the context of LISP+ALT is =
a EID-=0D
      prefix EID-prefix value of 0.0.0.0/0 =
(or 0::/0 for=0D
      ipv6) which is =
advertised by BGP on top of may be learned from the=0D
      ALT. ALT or statically configured=0D
      on an edge ALT Router.  The Default ALT-Default Route is used to realize defines a forwarding=0D
      path for Data Probe=0D
      or Map-Request packets.=0D
=0D
4. a packet to be sent =
into the ALT on a router which does=0D
      not have a full ALT forwarding database.=0D
=0D
3.  The LISP =
1.5 LISP+ALT=
 model=0D
=0D
   As documented in [LISP], the LISP =
1.5=0D
=0D
   The LISP+ALT model uses =
the same basic query/response protocol machinery as LISP 1.0. that=0D
   is documented in [LISP].  In particular, =
LISP+=0D
   ALT LISP+ALT provides two mechanisms for types=0D
   packet that an ITR can =
originate to obtain EID-to-RLOC mappings=0D
   (both mappings:=0D
=0D
   Map-Request:  A Map-Request message is sent into the ALT to request=0D=

      an EID-to-RLOC mapping.  The ETR which owns the mapping will=0D
      respond to the ITR with a Map-Reply message.  Since the ALT only=0D=

      forwards on EID destinations, the destination =
address of these techniques =
are described in more detail in=0D
   Section 9.2): the Map-=0D=

      Request sent on the ALT must be an EID.  See [LISP] for the format=0D=

      of Map-Request and Map-Reply packets.=0D
=0D
   Data Probe:  An  =
Alternatively, an ITR may =
encapsulate and send the =
first few=0D
      data packets =
packet destined for a EID with no known =
RLOCs into the ALT=0D
      to as=0D
      a Data Probe.  This might be done minimize packet =
loss and to=0D
      probe for the mapping; =
mapping.  As above, the =
authoritative ETR for the=0D
      EID-prefix will respond to the ITR with a =
Map-Reply message when=0D
      it receives the data packet over the ALT.  As a side-effect, the=0D
      encapsulated data packet is delivered to the end-system at the ETR=0D=

      site.  Note that in =
this=0D
      case, the Data =
Probe inner Destination =
Address (DA), IP =
destination address,=0D
      which is an EID, is copied to the outer DA and is IP =
destination address so=0D
      that the resulting packet can be routed over the =
ALT.=0D
=0D
   Map-Request:  An ITR may also =
send  See=0D
      Section 3.3 for caveats on the usability of Data Probes.=0D
=0D
   The term "ALT Datagram" is short-hand for a =
Map-Request message into the ALT=0D
      to request the mapping.  As in the or Data Probe case, the=0D
      authoritative ETR will respond=0D
   to be sent into or forwarded =
on the ITR with a Map-Reply=0D=

      message.  In this case, ALT.  Note that while the DA outer=0D
   header Source Address of the Map-Request MUST an ALT Datagram is currently expected to =
be=0D
   an EID.=0D
      See [LISP] RLOC, =
there may be situations (i.e. for the format of Map-Request and Map-Reply packets.=0D
=0D
   Like LISP 1.0, experimentation with=0D
   caching in intermediate ALT nodes) where an EID would be used to=0D
   force a Map-Reply to be routed back through the ALT.=0D
=0D
3.1.  Routeability of EIDs are=
 routable=0D
=0D
   A LISP EID has the same syntax as IP =
address and can be used,=0D
   unaltered, as the source and or destination addresses in of an IP datagrams.  Unlike in LISP=0D
   1.0, LISP 1.5 datagram. =
 In=0D
   general, though, EIDs are not routable on the public =
Internet; instead,=0D
   they are only routed over LISP+=0D
   ALT provides a separate, virtual topology referred to network, known as the LISP=0D
   Alternative Virtual =
Network. Logical Topology =
(ALT) on which a datagram using an EID=0D
   as an IP destination address may be transmitted.  =
This network is=0D
   built as an overlay on the public Internet using tunnels to=0D
   interconnect LISP+ALT=0D
   routers. ALT =
Routers.  BGP is =
run runs =
over these tunnels to propagate the=0D
   path information needed =
to route Data Probes and =
Map-Request/Replies. forward=
 ALT Datagrams.  Importantly, while=0D
   the ETRs are the source(s) of the unaggregated EID prefix data, EID-prefixes, LISP+ALT=0D
   uses existing BGP mechanisms to aggressively aggregate this information.  =
Note that ETRs are not =
required=0D
=0D
3.1.1.  Mechanisms for an =
ETR to participate (or=0D
   prevented from participating) in LISP+ALT; they =
originate EID-prefixes=0D
=0D
   There are three ways that an ETR may choose=0D
   communicate their originate its mappings to their serving LISP+ALT router(s) at=0D
   subscription time via configuration.  ITRs are also not required to=0D=

   participate into the=0D
   ALT:=0D
=0D
   1.  By registration with a Map Server as documented =
in (nor prevented from participating in) =
LISP+ALT.=0D
=0D
5.  LISP+ALT: Overview=0D
=0D
   LISP+ALT [LISP-MS].=0D
       This is a hybrid =
push/pull architecture.  Aggregated EID prefixes=0D
   are "pushed" among the LISP+ALT routers and, optionally, out to ITRs=0D
   (which may elect common =
case and is expected to receive be =
used by the aggregated =
information, as opposed to=0D
   simply using=0D
       majority of ETRs.=0D
=0D
   2.  Using a default =
mapping).  Specific EID-to-RLOC mappings are=0D
   "pulled" by ITRs when they either send explicit LISP requests or data=0D=

   packets "static =
route" on the alternate =
topology that result in triggered replies=0D
   being generated by ETRs.=0D
=0D
   The basic idea embodied in LISP+ALT ALT.  Where no Map-Server is =
to use BGP, running over=0D
       available, an=0D
   overlay network made up of Generic =
Routing Encapsulation (GRE)=0D
   tunnels, edge ALT =
Router may be configured with a "static=0D
       EID-prefix route" pointing to establish reachability required =
an ETR.=0D
=0D
   3.  Edge connection to route Data Probes,=0D
   Map-Requests, and Map-Replies over the alternate topology (ALT).  The=0D
   ALT RIB (BGP RIB) ALT.  =
If a site requires fine- grained=0D
       control over how its EID-prefixes are advertised in to the ALT,=0D=

       it may configure its ETR(s) with tunnel and BGP connections to=0D
       edge ALT Routers.=0D
=0D
3.1.2.  Mechanisms for an ITR to forward to EID-prefixes=0D
=0D
   There are three ways that an ITR may send ALT Datagrams:=0D
=0D
   1.  Through a Map Resolver as documented in [LISP-MS].  This is the=0D=

       common case and is expected to be used by the majority of ITRs.=0D=

=0D
   2.  Using a "default route".  Where a Map Resolver is not available,=0D=

       an ITR may be configured with a static ALT Default Route pointing=0D=

       to an edge ALT Router.=0D
=0D
   3.  Edge connection to the ALT.  If a site requires fine-grained=0D
       knowledge of what prefixes exist on the ALT, it may configure its=0D=

       ITR(s) with tunnel and BGP connections to edge ALT Routers.=0D
=0D
3.1.3.  Map Server Model preferred=0D
=0D
   The ALT-connected ITR and ETR cases are expected to be rare, as the=0D=

   Map Server/Map Resolver model is both simpler for an ITR/ETR operator=0D=

   to use, and provides a more general service interface to not only the=0D=

   ALT, but also to other mapping databases that may be developed in the=0D=

   future.=0D
=0D
3.2.  Connectivity to non-LISP sites=0D
=0D
   As stated above, EIDs used as IP addresses by LISP sites are not=0D
   routable on the public Internet.  This implies that, absent a=0D
   mechanism for communication between LISP and non-LISP sites,=0D
   connectivity between them is not possible.  To resolve this problem,=0D=

   an "interworking" technology has been defined; see [LISP-IW] for=0D
   details.=0D
=0D
3.3.  Caveats on the use of Data Probes=0D
=0D
   It is worth noting that there has been a great deal of discussion and=0D=

   controversy about whether Data Probes are a good idea.  On the one=0D
   hand, using them offers a method of avoiding the "first packet drop"=0D=

   problem when an ITR does not have a mapping for a particular EID-=0D
   prefix.  On the other hand, forwarding data packets on the ALT would=0D=

   require that it either be engineered to support relatively high=0D
   traffic rates, which is not generally feasible for a tunneled=0D
   network, or that it be carefully designed to aggressively rate-limit=0D=

   traffic to avoid congestion or DoS attacks.  There may also be issues=0D=

   caused by different latency or other performance characteristics=0D
   between the ALT path taken by an initial Data Probe and the=0D
   "Internet" path taken by subsequent packets on the same flow once a=0D=

   mapping is in place on an ITR.  For these reasons, the use of Data=0D
   Probes is not recommended at this time; they should only be=0D
   originated an ITR when explicitly configured to do so and such=0D
   configuration should only be enabled when performing experiments=0D
   intended to test the viability of using Data Probes.=0D
=0D
4.  LISP+ALT: Overview=0D
=0D
   LISP+ALT is a hybrid push/pull architecture.  Aggregated EID-prefixes=0D=

   are advertised among the ALT Routers and to those (rare) ITRs that=0D
   are directly connected via a tunnel and BGP to the ALT.  Specific=0D
   EID-to-RLOC mappings are requested by an ITR (and returned by an ETR)=0D=

   using LISP when it sends a request either via a Map Resolver or to an=0D=

   edge ALT Router.=0D
=0D
   The basic idea embodied in LISP+ALT is to use BGP, running on a=0D
   tunneled overlay network (the ALT), to establish reachability between=0D=

   ALT Routers.  The ALT BGPRoute Information Base (RIB) =
is comprised of EID prefixes =
(and=0D
   EID-prefixes and =
associated next=0D
   hops).  The LISP+ALT routers talk eBGP to =
each other in order to hops.=
  ALT Routers interconnect=0D
   using BGP and propagate EID EID-prefix=
 updates among themselves.  EID-=0D
   prefix update information, =
which information is learned either over=0D
   eBGP connections from ETRs at the authoritative ETR, "edge" of the ALT=0D
   either through the use of the Map Server interface (the commmon=0D
   case), static configuration, or by configuration.=0D
   ITRs may also eBGP peer with one or more LISP+ALT routers in =
order BGP-speaking ETRs.=0D=

=0D
   An ITR use the ALT to=0D
   route Data Probe packets or Map-Requests =
(more likely, learn the =
best path for forwarding an ALT=0D
   Datagram destined to a particular EID-prefix.  An ITR =
will=0D
   have normally=0D
   use a default mapping =
pointing at one Map =
Resolver to send its ALT Datagrams on to the ALT but may,=0D
   in unusual circumstances, use a static ALT Default =
Route or more LISP+ALT =
routers). connect=0D
   to the ALT using BGP.=0D
=0D
   Note that while this document explicitly specifies the use of =
GRE Generic Routing=0D
   Encapsulation (GRE) as a tunneling mechanism, there =
is no reason that a=0D
   parts of the ALT cannot =
be built using other tunneling technologies. =
 In technologies,=0D
   particularly in cases where GRE does not meet =
security, management,=0D
   or other operational requirements, it is=0D=

   reasonable to use another tunneling technology that =
does. requirements.  References to "GRE =
tunnel" in=0D
   later sections of this document should therefore not be taken as=0D
   prohibiting or precluding the use of other,=
 available other tunneling mechanisms.=0D
   Note also that two ALT Routers that are =
directly adjacent (with no=0D
   layer-3 router hops between them) need not use a tunnel between them;=0D=

   in this case, BGP may be configured across the interfaces that=0D
   connect to their common subnet and that subnet is then considered to=0D=

   be part of the ALT topology.  Use of techniques such as "eBGP=0D
   multihop" to connect ALT Routers that do not share a tunnel or common=0D=

   subnet is not recommended as the non-ALT Routers in between the ALT=0D=

   Routers in such a configuration may not have information necessary to=0D=

   forward ALT Datagrams destined to EID-prefixes exchanged across that=0D=

   BGP session.=0D
=0D
   In summary, LISP+ALT uses BGP to propagate =
EID-prefix update=0D
   information used by ITRs and ETRs build paths through ALT Routers so=0D
   that an ALT Datagram sent in to the ALT can be =
forwarded to forward =
Map-Requests, Map-=0D
   Replies, and Data Probes. the ETR=0D
   that holds the EID-to-RLOC mapping for that =
EID-prefix.  This=0D
   reachability is carried as IPv4 or=0D
   IPv6 ipv6 NLRI without modification=0D
   (since the EID space =
an EID-prefix has the same =
syntax as IPv4 or IPv6).  LISP+ALT routers =
eBGP peer ipv6 address=0D
   prefix).  ALT Routers establish BGP sessions with one =
another,=0D
   forming the ALT.  An LISP+ALT router =
near ALT Router =
at the edge =
"edge" of the topology =
learns=0D
   EID prefixes which are=0D
   EID-prefixes originated =
by authoritative ETRs, =
either ETRs.  Learning may =
be=0D
   though the Map Server interface, by=0D
   eBGP peering =
static configuration, or via =
BGP=0D
   with them the ETRs.  An ALT Router may also be configured to =
aggregate=0D
   EID-prefixes received from ETRs or by configuration. from other LISP+ALT routers=0D
   aggregate EID prefixes, and forward Data =
Probes, Map-Requests, and=0D
   Map-Replies.=0D
=0D
5.1. that=0D
   are topologically "downstream" from it.=0D
=0D
4.1.  ITR traffic handling=0D
=0D
   When an ITR receives a packet originated by an end system =
within withind its=0D
   site (i.e. a host for which the ITR is the exit path out of the site)=0D=

   and the destination EID =
for that packet is not known in the ITR's=0D
   mapping cache, the ITR encapsulates the =
packet in creates =
either a LISP header, =
copying Map-Request =
for the=0D
   inner=0D
   destination address (EID) =
to EID or =
the outer destination address=0D
   (RLOC), and transmits it through original packet encapsulated as a =
GRE tunnel Data Probe=0D
   (see Section 3.3 for caveats on the usability of Data Probes).  The=0D=

   result, known as an ALT Datagram, is then sent to an ALT Router (see=0D=

   also [LISP-MS] for non-ALT-connected ITRs, noting that Data Probes=0D
   cannot be sent to a LISP+ALT router in=0D
   the ALT. Map-Resolver).  This "first hop" =
LISP+ALT router =
ALT Router uses=0D
   EID-prefix routing information learned from other LISP+ALT routers ALT Routers via BGP=0D
   to guide the packet to the ETR which "owns" the prefix.  Upon receipt=0D=

   by the ETR, normal LISP processing occurs: the ETR responds to the=0D
   ITR with a LISP Map-Reply that lists the RLOCs (and, thus, the ETRs=0D=

   to use) for the EID prefix.  =
The EID-prefix.  For Data =
Probes, the ETR also de-encapsulates=0D
   decapsulates the packet =
and transmits it toward its destination.=0D
=0D
   Upon receipt of the Map-Reply, the ITR installs the RLOC information=0D=

   for a given prefix into a local mapping database.  With these mapping=0D=

   entries stored, additional packets destined to the given =
EID prefix EID-prefix=0D
   are routed directly to a viable =
ETR an =
RLOC without use of the ALT, until either=0D
   the entry's TTL has expired, or the ITR can otherwise find no=0D
   reachable ETR.  Note that a valid current mapping (not timed-out) may exist that contains=0D
   no reachable RLOCs (i.e. all paths to =
that ETR are=0D
   down); in RLOCs; this case, is =
known as a Negative Cache Entry and it=0D
   indicates that packets destined to the EID prefix EID-prefix are dropped,=0D
   not routed through the ALT. to be dropped.=0D
=0D
   Full details on Map-Request/Map-Reply processing may be found in=0D
   [LISP].=0D
=0D
   Traffic routed over =
on to the ALT =
therefore consists =
of:=0D
=0D
   o  EID prefix Map-Requests, solely of ALT Datagrams, i.e.=0D
   Map-Requests and=0D
=0D
   o  data packets destined for those EID =
prefixes while Data Probes =
(if supported).  Given the relatively=0D
   low performance expected of a tuneled topology, ALT Routers (and Map=0D=

   Resolvers) should aggressively rate-limit the =
ITR awaits=0D
      map replies=0D
=0D
5.2. ingress of ALT=0D
   Datagrams from ITRs and, if possible, should be configured to not=0D
   accept packets that are not ALT Datagrams.=0D
=0D
4.2.  EID Assignment - Hierarchy and Topology=0D
=0D
   EID-prefixes will =
are expected to be =
allocated to a LISP site by Internet=0D
   Registries.=0D
   Multiple allocations may not be =
in  Where a site has =
multiple aggregations which are aligned=0D
   on a power-of-2 blocks.  =
But when they=0D
   are, block =
boundary, they will should be aggregated into a =
single, advertised =
EID-prefix.=0D
   single EID-prefix for =
advertisement.  The ALT network is built in a =
tree-structured hierarchy=0D
   roughly hierarchical, partial mesh =
which is intended to allow=0D
   proxy=0D
   aggregation at merge points in the =
tree. where =
clearly-defined hierarchical boundaries exist.=0D
   Building such a structure should minimize the number of EID-prefixes=0D=

   carried by LISP+=0D
   ALT LISP+ALT nodes near the top of the =
hierarchy.=0D
=0D
   Since=0D
=0D
   Routes on the ALT =
will do not need to change due respond to subscription changes in policy,=0D
   subscription, or policy=0D=

   reasons, underlying =
physical connectivity, so the topology=0D
   can remain relatively static and aggregation can be sustained.=0D
   Because routing on the ALT uses BGP, the same rules apply for=0D
   generating aggregates; in particular, a LISP+ALT=0D
   router ALT =
Router should only be=0D
   configured to generate an aggregate if it is=0D
   able configured with BGP=0D
   sessions to learn =
reachability information for all of the originators of components =
(more-=0D
   specific (more-specifics=0D
   prefixes) of that aggregate. aggregate.  Not all of the components of need to be=0D
   present for the aggregate to be originated (some may be holes in the=0D=

   covering prefix and some may be down) but the aggregating router must=0D=

   be configured to learn the state of all of the components.=0D
=0D
   Under what circumstances the ALT Router actually generates the=0D
   aggregate is a matter of local policy: in some cases, it will be=0D
   statically configured to do so at all times with a "static discard"=0D=

   route.  In other cases, it may be configured to only generate the=0D
   aggregate prefix if at least one of the components of the aggregate=0D=

   is learned via BGP.=0D
=0D
   An ALT Router must not genearte an aggregate that includes a non-=0D
   LISP-speaking hole unless it can be configured to return a Negative=0D=

   Map-Reply with action=3D"Natively-Forward" (see [LISP]) if it =
receives=0D
   an ALT Datagram that matches that hole.  If it receives an ALT=0D
   Datagram that matches a LISP-speaking hole that is currently not=0D
   reachable, it should return a Negative Map-Reply with action=3D"drop".=0D=

   Negative Map-Replies should be returned with a short TTL, as=0D
   specified in [LISP-MS].  Note that an off-the-shelf, non-LISP-=0D
   speaking router configured as an aggregating ALT Router cannot send=0D=

   Negative Map-Replies, so such a router must never originate an=0D
   aggregate that includes a non-LISP-speaking hole.=0D
=0D
   This means, for example, =
implies that two =
ALTs ALT Routers that share an overlapping =
set of=0D
   prefixes must exchange those prefixes if either is to generate and=0D
   export a covering aggregate for those prefixes.=0D
=0D
   Note: much is currently uncertain about =
the best way  It also =
implies that=0D
   an ETR which connects to build the ALT=0D
   network; as testing and prototype =
deployment proceeds, a guide to how=0D
   to best build using BGP =
must maintain BGP sessions=0D
   with all of the ALT network=
 will Routers that are =
configured to originate an=0D
   aggregate which covers that prefix and that each of those ALT Routers=0D=

   must be developed.=0D
=0D
5.3.  LISP+ALT Router=0D
=0D
   A LISP+ALT Router has the following functionality:=0D
=0D
   1.  It runs, at a minimum, explicitly configured to know the =
eBGP part set of the =
BGP protocol.=0D
=0D
   2.  It supports a separate RIB which uses next-hop GRE tunnel=0D
       interfaces EID-prefixes that=0D
   make up any aggregate that it originates.  See also =
[LISP-MS] for forwarding =
Data Probes an=0D
   example of other ways that prefix origin consistency =
and Map-Requests.=0D
=0D
   3.  It can act as a "proxy-ITR" to support non-LISP sites.=0D
=0D
   4.  It can act as aggregation=0D
   are maintained.=0D
=0D
   As an ETR, or as a =
recursive or re-encapsulating ITR=0D
       to reduce mapping tables in site-based LISP routers.=0D
=0D
5.4.  ITR example, =
consider ETRs that are originating EID-prefixes for=0D
   10.1.0.0/24, 10.1.64.0/24, 10.1.128.0/24, and =
ETR in a LISP+ALT =
Environment 10.1.192.0/24.  An ITR using LISP+ALT may have additional functionality as =
follows:=0D
=0D
   1.  If it is also acting as a LISP+ALT Router, =
ALT=0D
   Router should only be configured to generate an aggregate for=0D
   10.1.0.0/16 if it sends =
Data Probes=0D
       or Map-Requests on the has BGP best =
path computed GRE tunnel for each=0D
       EID prefix.=0D
=0D
   2.  When acting solely as a ITR, sessions configured with all of these ETRs,=0D
   in other words, only if it sends Data Probes or Map-Requests=0D
       directly has =
sufficient knowledge about the state=0D
   of those prefixes to a =
configured LISP+ALT router.=0D
=0D
   An ETR using LISP+ALT may also behave slightly differently:=0D
=0D
   1. summarize =
them.  If the Router =
originating=0D
   10.1.0.0/16 receives an ALT Datagram destined for 10.1.77.88, a non-=0D=

   LISP destination covered by the aggregate, it =
is also acting as =
returns a LISP+ALT router, Negative Map-=0D
   Reply with action "Natively-Forward".  If it =
advertises its=0D
       configured EID-prefixes into BGP receives an ALT Datagram=0D
   destined for distribution =
through 10.1.128.199 =
but the=0D
       ALT.=0D
=0D
   2.  It receives Data Probes and Map-Requests only over GRE =
tunnel(s) configured LISP =
prefix=0D
   10.1.128.0/24 is unreachable, it returns a Negative Map-Reply with=0D
   action "drop".=0D
=0D
   Note: much is currently uncertain about the best way =
to its "upstream" LISP+ALT =
router(s) build the ALT=0D
   network; as testing and responds with Map-=0D
       Replies for prototype=
 deployment proceeds, a guide to how=0D
   to best build the EID =
prefixes that it "owns".=0D
=0D
5.5. ALT network will be =
developed.=0D
=0D
4.3.  Use of GRE and BGP between LISP+ALT Routers=0D
=0D
   The ALT network is built using GRE tunnels between LISP+ALT routers.=0D
   eBGP ALT Routers.  =
BGP=0D
   sessions are configured over those tunnels, with each LISP+ALT=0D
   router ALT =
Router=0D
   acting as a separate AS "hop" in a Path Vector for BGP.  For the=0D
   purposes of LISP+ALT, the AS-path is used solely as a shortest-=0D
   path shortest-path=0D
   determination and loop-avoidance mechanism.  Because all =
next-=0D
   hops next-hops=0D
   are on tunnel interfaces, no IGP is required to resolve those=0D
   next-hops next-=0D
   hops to exit interfaces.=0D
=0D
   LISP+ALT's use of GRE and BGP reduces =
provider Operational Expense=0D
   (OPEX) facilities =
deployment and operation of=0D
   LISP because no new protocols need to be =
either defined defined, implemented, or=0D
   used on the overlay topology.  =
Also, topology; existing =
BGP/GRE tools and operational=0D
   expertise are also re-used.  Tunnel address assignment is also =
easy:=0D
   since the addresses on an =
ALT tunnel are only used =
by the pair of=0D
   routers connected to the tunnel, the only requirement of =
the IP=0D
   addresses are local in=0D
   scope, no coordination used to establish that tunnel is =
needed for their assignment; =
that the attached routers=0D
   be reachable by each other; any addressing=0D
   scheme (including =
plan, including private =
addressing)=0D
   addressing, can =
therefore be used for =
tunnel=0D
   addressing.=0D
=0D
6.  EID-to-RLOC mapping propagation ALT tunnels.=0D
=0D
5.  EID-prefix Propagation and Map-Request Forwarding=0D
=0D
   As described in Section 9.2, 8.2, an ITR may send either a Map-Request or=0D
   a data probe sends an =
ALT Datagram to find a given=0D
   EID-to-RLOC mapping.  The ALT provides the infrastructure that allows=0D=

   these requests to reach the authoritative ETR, and possibly for ETR.=0D
=0D
   Note that under normal circumstances Map-Replies are not sent =
over=0D
   the reply ALT - an ETR sends a Map-Reply to =
find its way back =
the source RLOC learned from=0D
   the original Map-Request.  There may be scenarios, =
perhaps to=0D
   encourage caching of EID-to-RLOC =
mappings by ALT Routers, where Map-=0D
   Replies could be sent over the requesting ITR (the ETR ALT or where a "first-hop" ALT router=0D
   might choose =
modify the originating RLOC on a =
Map-Request received from an=0D
   ITR to send=
 force the Map-Reply to =
be returned to the=0D
   requesting ITR's source-RLOC, bypassing =
the ALT). "first-hop" ALT=0D=

   Router.  These cases will not be supported by initial =
LISP+ALT routers=0D
   implementations but may be subject to =
future experimentation.=0D
=0D
   ALT Routers propagate mapping path information for use via =
BGP ([RFC4271]) that is=0D
   used by ITRs (when=0D
   making Map-Requests or sending Data Probes), and ETRs (if the ETR is=0D=

   configured to send Map-Replies back to the requesting ITR =
over ALT Datagrams =
toward the=0D
   ALT) using eBGP [RFC4271]. =
eBGP appropriate ETR for=0D=

   each EID-prefix.  BGP is run on the inter-LISP+ALT router inter-ALT Router links, and =
and=0D
   possibly between an edge LISP+ALT =
router ("last hop") ALT =
Router and an ETR or=0D
   between an edge LISP+ALT =
router ("first hop") ALT =
Router and an ITR.  The ALT eBGP BGP RIB=0D
   consists of aggregated EID =
prefixes EID-prefixes and their next hops toward =
the=0D
   authoritative ETR for that EID prefix.=0D
=0D
6.1. EID-prefix.=0D
=0D
5.1.  Changes to ITR behavior with LISP+ALT=0D
=0D
   As previously described, an ITR will =
usually use the Map Resolver=0D
   interface and will send its Map Requests to a Map =
Resolver.  When using =
LISP+ALT, an=0D
   ITR always instead connects via tunnels and BGP to the ALT, =
it sends either Data Probes =
or Map-=0D
   Requests ALT=0D
   Datagrams to one of its "upstream" LISP+ALT routers. ALT Routers; these are sent only=0D
   to obtain new EID-to-RLOC mappings - RLOC probe and cache TTL refresh=0D=

   Map-Requests are not sent on the ALT.  As in basic =
LISP, it should=0D
   use one of its RLOCs as the source address of these queries; it=0D
   should explicitly not use =
a tunnel interface as the source address as doing so=0D
   will cause replies to be forwarded over the tunneled topology and may=0D=

   be problematic if the tunnel interface address is not explicitly routed=0D
   throughout the ALT.  If the ITR is running BGP with the LISP+ALT=0D
   router(s), it selects the appropriate=0D
   LISP+ALT router =
ALT Router based on the =
BGP=0D
   information received.  If it is not running BGP, it uses =
static configuration =
a=0D
   statically-configued ALT Default Route to select =
a LISP+ALT=0D
   router; in the general case, this will effectively be =
an "EID-prefix=0D
   default route".=0D
=0D
6.2. ALT Router.=0D
=0D
5.2.  Changes to ETR behavior with LISP+ALT=0D
=0D
   If=0D
=0D
   As previously described, an ETR will =
usually use the Map Server=0D
   interface (see [LISP-MS]) and will register its EID-prefixes with its=0D=

   configured Map Servers.  When an ETR instead connects using BGP to=0D
   one or more LISP+ALT =
router(s), ALT =
Routers, it=0D
   simply announces its =
EID-prefix EID-prefix(es) to those LISP+ALT routers.  In the=0D
   "low-opex" case, where the ETR does not use BGP, it will still have a=0D=

   GRE tunnel to one or more LISP+ALT routers; these LISP+ALT router(s)=0D=

   the ETR must route Map-Requests and Data Probes to the ETR and=0D
   contain configuration (in effect, static routes) for the ETR's EID-=0D=

   prefixes. ALT=0D
   Routers.  Note that in =
either case, when an ETR generates a Map-=0D
   Reply Map-Reply message to=0D
   return to a querying ITR, it sends it to the ITR's source-RLOC (i.e.,=0D=

   on the underlying Internet topology, not on the ALT; this avoids any=0D=

   latency penalty (or =
"stretch") that might be incurred by routing over=0D
   the ALT).=0D
=0D
   See also Section 9 for more details about =
the "low-opex" ETR and ITR=0D
   configurations.=0D
=0D
7.=0D
=0D
6.  BGP configuration and =
protocol considerations=0D
=0D
7.1.=0D
=0D
6.1.  Autonomous System =
Numbers (ASNs) in LISP+ALT=0D
=0D
   The primary use of BGP today is to define the global Internet routing=0D=

   topology in terms of its participants, known as Autonomous Systems.=0D=

   LISP+ALT specifies the use of BGP to create a global overlay network=0D
   (the ALT) for finding EID-to-RLOC=0D
   mapping database which, =
while mappings.  =
While related to the=0D
   global routing database, the =
ALT serves a very different purpose and=0D
   is organized into a very different hierarchy.  Because LISP+ALT does=0D=

   use BGP, however, it uses ASNs in the paths that are propagated among =
LISP+ALT routers.=0D
   ALT Routers.  To avoid =
confusion, it needs to be stressed that that=0D
   these LISP+ALT ASNs use a new numbering space that is unrelated to=0D
   the ASNs used by the global routing system.  Exactly how this new=0D
   space will be assigned and managed will be determined during =
experimental the=0D
   deployment of LISP+ALT.=0D
=0D
   Note that the LISP+ALT =
routers the ALT =
Routers that make up the "core" of the ALT will not=0D
   be associated with any existing core-Internet ASN because=0D
   topology, hierarchy, and aggregation =
boundaries are the ALT=0D
   topology is completely separate from from, and independent of of, the global=0D
   Internet routing system.=0D
=0D
7.2.=0D
=0D
6.2.  Sub-Address Family =
Identifier (SAFI) for LISP+ALT=0D
=0D
   As defined by this document, LISP+ALT may be implemented using BGP=0D
   without modification.  Given the fundamental operational difference=0D=

   between propagating global Internet routing information (the =
current, current=0D
   dominant use of BGP) and managing the =
global EID-to-RLOC database creating an overlay network for finding EID-=0D
   to-RLOC mappings (the use of BGP proposed by this =
document), it may=0D
   be desirable to assign a new SAFI [RFC2858] to prevent operational=0D
   confusion and difficulties, including the inadvertent leaking of=0D
   information from one domain to the other.  Use of a separate SAFI=0D
   would make it easier to debug many operational problems but would=0D
   come at a significant cost: unmodified, off-the-shelf routers which=0D=

   do not understand the new SAFI could not be used to build any part of=0D=

   the ALT network.  At present, this document does not =
require request the=0D
   assignment of a new SAFI but the authors =
anticipate that SAFI; =
additional experimentation may suggest the=0D
   need for one in the future.=0D
=0D
8.  EID-Prefix=0D
=0D
7.  EID-prefix Aggregation=0D=

=0D
   The ALT BGP peering topology should be arranged in a tree-like=0D
   fashion (with some meshiness), with redundancy to deal with node and=0D=

   link failures.  A basic assumption is that as long as the routers are=0D=

   up and running, the underlying topology Internet will provide alternative=0D
   routes to maintain BGP connectivity among LISP+ALT routers. ALT Routers.=0D
=0D
   Note that, as mentioned in Section 5.2, 4.2, the use of BGP by LISP+ALT=0D
   requires that information can only be aggregated where all active=0D
   more-specific =
more-=0D
   specific prefixes of a generated aggregate prefix are =
known.  This implies, for example, that if a =
given set of prefixes is used by=0D
   multiple, ALT networks, those networks must interconnect and share=0D
   information about all of the prefixes if either were to generate an=0D=

   aggregate prefix that covered all of them.  This is=0D=

   no different than the way that BGP route aggregation works in the=0D
   existing global routing system: a service provider only generates an=0D=

   aggregate route if it has =
connectivity is configured =
to learn to all prefixes that=0D
   make up that aggregate.=0D
=0D
8.1.  Traffic engineering with LISP and =
LISP+ALT=0D
=0D
7.1.  Stability of the ALT=0D=

=0D
   It is worth noting that LISP+ALT does not directly propagate EID-to-=0D=

   RLOC mappings.  What it does is provide a mechanism for a LISP an ITR to=0D
   find=0D
   commonicate with the =
ETR that holds the mapping for a particular EID EID-=0D
   prefix.  This distinction is important when considering the stability=0D
   of BGP on the ALT network as compared to the global routing system.=0D=

   It also has implications for several reasons.  First, it means=0D
   that how site-specific =
EID-prefix information=0D
   may be used by LISP but not propagated by LISP+ALT (see Section 7.2=0D=

   below).=0D
=0D
   RLOC prefixes are not propagated through the =
ALT so their=0D
   reachability is not determined through use of LISP+ALT.  =
Instead,=0D
   reachability of RLOCs is learned through the LISP ITR-ETR=0D
   exchange so "flapping" =
exchange.=0D
   This means that link failures or other service disruptions that may=0D=

   cause the reachability of state information through an RLOC to change are not known to the ALT.=0D
   Changes to the presence of an EID-prefix on the ALT occur much less=0D=

   frequently: only at subscription time or in the event of a failure of=0D=

   the ALT infrastructure itself.  This means that "flapping" =
(frequent=0D
   BGP updates and withdrawals due to =
prefix state changes) is not=0D
   likely=0D
   nor can and mapping information cannot become "stale" by due =
to slow=0D
   propagation through the ALT BGP mesh.  Second, by deferring=0D
=0D
7.2.  Traffic engineering using LISP=0D
=0D
   Since an ITR learns an EID-to-RLOC mapping=0D
   to an ITR-ETR exchange, =
directly from the ETR that=0D
   owns it, it is possible to perform site-to-site =
traffic engineering through a combination =
of=0D
   by setting the =
preference=0D
   and and/or weight fields fields, and by returning including=0D
   more-specific EID-to-RLOC information in LISP Map-Reply messages.=0D
=0D
   This is a powerful mechanism that can conceivably replace the=0D
   traditional practice of routing prefix deaggregation for traffic=0D
   engineering purposes.  Rather than propagating more-specific=0D
   information into the global routing system for local- or =
regional-optimization =
regional-=0D
   optimization of traffic flows, such more-=0D
   specific more-specific information can be=0D
   exchanged, through LISP (not LISP+ALT), on an as-needed basis between=0D=

   only those ITRs/ETRs (and, thus, site pairs) that need it; should it.=
  Should a=0D
   receiving ITR decide that it does not wish to store such =
more-specific more-=0D
   specific information, it has the option of discarding =
it as long as a=0D
   shorter, covering EID =
prefix EID-prefix exists.  Not=0D
   only does this greatly improve the scalability  =
Such an exchange of =
the global routing=0D
   system but it also allows improved "more-=0D
   specifics" between sites facilitates traffic =
engineering techniques =
engineering, by allowing=0D=

   richer and more fine-grained policies to be applied without=0D
   advertising additional prefixes into either the ALT or the global=0D
   routing system.=0D
=0D
   Note that these new traffic engineering capabilities are an attribute=0D=

   of LISP and are not specific to LISP+ALT; discussion is included here=0D=

   because the BGP-based global routing system has traditionally used=0D
   propagation of more-specific routes as a crude form of traffic=0D
   engineering.=0D
=0D
7.3.  Edge aggregation and dampening=0D
=0D
   Normal BGP best common practices apply to the ALT network.  In=0D
   particular, first-hop ALT Routers will aggregate EID prefixes and=0D
   dampen changes to them in the face of excessive updates.  Since EID-=0D=

   prefix assignments are not expected to change as frequently as global=0D=

   routing BGP prefix reachability, such dampening should be very rare,=0D=

   and might be worthy of logging as an exceptional event.  It is again=0D=

   worth noting that the ALT carries only EID-prefixes, used to=0D
   construct BGP paths to their owning ETRs; it does not carry=0D
   reachability about RLOCs.  In addition, EID-prefix information may be=0D=

   aggregated as the topology and address assignment hierarchy allow.=0D
   Since the topology is all tunneled and can be modified as needed,=0D
   reasonably good aggregation should be possible.  In addition, since=0D=

   most ETRs are expected to connect to the ALT using the Map Server=0D
   interface, Map Servers will implement a natural "edge" for the ALT=0D
   where dampening and aggregation can be applied.=0D
=0D
9.  For these reasons,=0D
   the set of prefix information on the ALT can be expected to be both=0D=

   better aggregated and considerably less volatile than the actual EID-=0D=

   to-RLOC mappings.=0D
=0D
8.  Connecting sites to the ALT network=0D
=0D
9.1.=0D
=0D
8.1.  ETRs originating =
information into the ALT=0D
=0D
   EID prefix=0D
=0D
   EID-prefix information =
is originated into the ALT by two three different=0D
   mechanisms:=0D
=0D
   eBGP:  An ETR may=0D
=0D
   Map Server:  In most cases, a site will =
configure its ETR(s) to=0D
      register with one or more Map Servers (see [LISP-MS]), and does=0D
      not participate directly in the ALT.=0D
=0D
   BGP:  For a site requiring complex control over their EID-prefix=0D
      origination into the ALT, an ETR may connect to =
the LISP+ALT=0D
      overlay network by running eBGP BGP to one or more LISP+ALT router(s) ALT Router(s) over GRE=0D
      tunnel(s).=0D
      In this case, the  =
The ETR advertises =
reachability for its EID =
prefixes EID-prefixes=0D
      over these eBGP =
BGP connection(s).  The =
LISP+ALT router(s) =
edge ALT Router(s) that=0D
      receive(s) these prefixes then propagate(s) them into the ALT.=0D
      Here the ETR is simply an eBGP BGP peer of LISP+ALT router(s) ALT Router(s) at the edge of=0D
      the ALT.  Where possible, a LISP+ALT =
router an ALT =
Router that receives=0D
      EID prefixes =
EID-prefixes=0D
      from an ETR via eBGP =
BGP should aggregate that =
information.=0D
=0D
   Configuration:  One or more LISP+ALT =
router(s) ALT =
Router(s) may be configured to=0D
      originate an EID =
prefix EID-prefix on behalf of the =
non-BGP-speaking ETR that=0D
      is authoritative for a prefix.  As in the case above, the ETR is=0D=

      connected to LISP+ALT =
router(s) ALT =
Router(s) using GRE tunnel(s) but rather than BGP=0D
      being used, the LISP+ALT =
router(s) ALT =
Router(s) are configured with what are in=0D
      effect "static routes" for the EID =
prefixes EID-prefixes "owned" by the ETR.=0D
      The GRE tunnel is used to route Map-Requests to the ETR=0D
      (if necessary), and for the ETR to respond with Map-Replies.  Of=0D=

      course, the LISP+ALT router could also serve as a proxy for its=0D
      TCP-connected ETRs. ETR.=0D
=0D
   Note:  in both =
all cases, an ETR may =
have connections =
register to multiple Map Servers or=0D
      connect to multiple=0D
      LISP+ALT routers =
ALT Routers for the =
following reasons:=0D
=0D
      *  redundancy, so that a particular ETR is still reachable =
through=0D
         the ALT even if=0D
         one path or tunnel is unavailable.=0D
=0D
      *  to connect to different parts of the ALT hierarchy if the ETR=0D=

         "owns" multiple EID-to-RLOC mappings for EID prefixes EID-prefixes that=0D
         cannot be aggregated by the same LISP+ALT router ALT Router (i.e. are not=0D
         topologically "close" to each other in the ALT).=0D
=0D
9.2.=0D
=0D
8.2.  ITRs Receiving Information from Using the ALT=0D
=0D
   In order to source Map-Requests =
to the ALT and receive =
Map-Replies=0D
   from common =
configuration, an ITR does not need to know anything=0D
   about the ALT, or since it =
sends Map-Requests to route one of =
its configured=0D
   Map-Resolvers (see [LISP-MS]).  There are two exceptional cases:=0D
=0D
   Static default:  If a Data =
Probe packet over the ALT, each Map Resolver is not available but an ITR=0D=

   participating in the =
is=0D
      adjacent to an ALT establishes Router (either over a connection to one or more=0D
   LISP+ALT routers.  These connections can be either =
eBGP common =
subnet or TCP (as=0D
   described above).=0D
=0D
   In the case in which the ITR is running eBGP, =
through=0D
      the peer LISP+ALT=0D
   routers use these =
connections to advertise highly aggregated EID-=0D
   prefixes to the peer ITRs.  The ITR then installs the received=0D
   prefixes into of a forwarding table that is used to to send LISP Map-=0D
   Requests tunnel), it =
can use an ALT Default Route route to the appropriate LISP+ALT router.  In most cases, a =
LISP+=0D
      cause all ALT =
router will send a default =
mapping Datagrams to its client ITRs so be sent that=0D
   they can send request for any EID prefix =
into the ALT.=0D
=0D
   In the ALT Router.  =
This case in which the =
ITR is connected=0D
      expected to =
some set of LISP+ALT=0D
   routers without eBGP, the ITR sends Map-Requests =
be rare.=0D
=0D
   Connection to any ALT:  A =
site with complex Internet connectivity needs=0D
      may need more fine-grained distinction between traffic to LISP-=0D
      capable and non-LISP-capable sites.  Such a site may configure=0D
      each of its=0D
   connected LISP+ALT routers, and receives =
Map-Replies from the LISP+=0D
   ALT router that has the "shortest path" ITRs to the =
authoritative ETR.=0D
=0D
   An ITR may also choose connect directly to send the first few data packets over the=0D=

   ALT to minimize packet =
loss ALT, using a =
tunnel=0D
      and reduce mapping =
latency. BGP =
connection.  In this case, the data packet serves as a mapping probe (Data Probe) and the=0D=

   ETR which receives the data packet (over the ALT) responds with a=0D
   Map-Reply that is either routed back over =
ITR will receive EID-prefix=0D
      routes from its BGP connection to the ALT =
or Router and will LISP-=0D
      encapsulate and send ALT Datagrams through the tunnel to the=0D=

   ITR's source-RLOC over =
ALT=0D
      Router.  Traffic to other destinations may be forwarded (without=0D=

      LISP encapsulation) to non-LISP next-hop routers =
that the underlying =
topology. ITR=0D
      knows.=0D
=0D
      In general, an ITR will establish =
connections that connects =
to the ALT does so only to LISP+ALT=0D
   routers to ALT=0D
      Routers at the "edge" of the ALT (typically two =
for redundancy) but=0D
   there may also redundancy).=0D
      There may, though, be situations where an ITR =
would connect to=0D
      other=0D
   LISP+ALT routers =
ALT Routers to receive =
additional, shorter path information=0D
      about a portion of the ALT of interest to it.  This can be=0D
      accomplished by establishing GRE tunnels between the ITR and the=0D=

      set of LISP+ALT =
routers ALT =
Routers with the additional information.  This is a=0D
      purely local policy issue between the ITR and the LISP+ALT routers ALT Routers in=0D
      question.=0D
=0D
10.=0D
=0D
   As described in [LISP-MS], =
Map-Resolvers do not accept or forward=0D
   Data Probes; in the rare scenario that an ITR does support and=0D
   originate Data Probes, it must do so using one of the exceptional=0D
   configurations described above.  Note that the use of Data Probes is=0D=

   discouraged at this time (see Section 3.3).=0D
=0D
9.  IANA Considerations=0D
=0D
   This document makes no request of the IANA.=0D
=0D
11.=0D
=0D
10.  Security =
Considerations=0D
=0D
   LISP+ALT shares many of the security characteristics of BGP.  Its=0D
   security mechanisms are comprised of existing technologies in wide=0D
   operational use today.  Securing =
LISP+ALT today, so =
securing the ALT should be mostly a matter=0D
   of applying the same technology that is much simpler than=0D
   securing BGP.=0D
=0D
   Compared to BGP, LISP+ALT routers are not topologically bound,=0D
   allowing them used to be =
put in locations away from secure the vulnerable AS=0D
   border (unlike eBGP speakers).=0D
=0D
11.1. BGP-based=0D
   global routing system (see Section 10.3 below).=0D
=0D
10.1.  Apparent LISP+ALT Vulnerabilities=0D
=0D
   This section briefly lists of the apparent known=
 potential vulnerabilities of LISP+=0D
   ALT.=0D
   LISP+ALT.=0D
=0D
   Mapping Integrity:  Can an attacker insert bogus mappings to black-=0D=

      hole (create a DoS) =
Denial-of-Service, or DoS =
attack) or intercept LISP=0D
      data-plane packets?=0D
=0D
   LISP+ALT router=0D
=0D
   ALT Router =
Availability:  Can an attacker DoS the LISP+ALT=0D
      routers ALT =
Routers=0D
      connected to a given ETR? without =
access to  If a site's ETR =
cannot advertise its=0D
      EID-to-RLOC =
mappings,=0D
      a the site is essentially unavailable.=0D
=0D
   ITR Mapping/Resources:  Can an attacker force an ITR or LISP+ALT=0D
      router ALT =
Router to=0D
      drop legitimate mapping requests by flooding it with random=0D
      destinations that =
for which it will =
have to query for. =
generate large numbers of Map-=0D
      Reqeusts and fill its mapping cache?  Further =
study is required to=0D
      see the impact of admission control on the overlay network.=0D
=0D
   EID Map-Request Exploits for Reconnaissance:  Can an attacker learn=0D=

      about a LISP destination =
sites' site's TE policy by sending legitimate =
mapping=0D
      requests messages and =
then observing the RLOC mapping replies?  Is this=0D
      information useful in attacking or subverting peer relationships?=0D=

      Note that any public =
LISP 1.0 has a mapping database will have similar =
data-plane data-=0D
      plane reconnaissance issue.=0D
=0D
   Scaling of LISP+ALT =
router ALT =
Router Resources:  Paths through the ALT may be of=0D
      lesser bandwidth than more "direct" paths; this may make them more=0D=

      prone to high-volume denial-of-service attacks.  For this reason,=0D
      all components of the ALT (ETRs and ALT Routers) should be=0D
      prepared to rate-limit traffic (ALT Datagrams) that could be=0D
      received across the ALT.=0D
=0D
   UDP Map-Reply from ETR:  If=
  Since Map-Replies =
packets are sent directly =
from the=0D
      ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various=0D=

      types of DoS attacks.=0D
=0D
11.2. attacks (this is a =
general property of LISP, not an=0D
      LISP+ALT vulnerability).=0D
=0D
   More-specific prefix leakage:  Because EID-prefixes on the ALT are=0D
      expected to be fairly well-aggregated and EID-prefixes propagated=0D=

      out to the global Internet (see [LISP-IW] much more so, accidental=0D=

      leaking or malicious advertisement of an EID-prefix into the=0D
      global routing system could cause traffic redirection away from a=0D=

      LISP site.  This is not really a new problem, though, and its=0D
      solution can only be achieved by much more strict prefix filtering=0D=

      and authentication on the global routing system.=0D
=0D
10.2.  Survey of LISP+ALT Security Mechanisms=0D
=0D
   Explicit peering:  The devices themselves can both prioritize=0D
      incoming packets =
packets, as well as =
potentially do key checks in hardware=0D
      to protect the control plane.=0D
=0D
   Use of TCP to connect elements:  This makes it difficult for third=0D
      parties to inject packets.=0D
=0D
   Use of HMAC Protected TCP =
BGP/TCP Connections:  HMAC =
is used to verify=0D
      message integrity and authenticity, making it nearly impossible=0D
      for third party devices to either insert or modify messages.=0D
=0D
   Message Sequence Numbers and Nonce Values in Messages:  This allows=0D=

      for devices=0D
      an ITR to verify =
that the mapping-reply packet =
was Map-Reply from an ETR =
is in response to the =
mapping-request=0D
      a Map-Request originated =
by that they sent.=0D
=0D
11.3.  Using existing ITR =
(this is a general property=0D
      of LISP; LISP+ALT does not change this behavior).=0D
=0D
10.3.  Use of new IETF standard BGP Security mechanisms=0D=

=0D
   LISP+ALT's use of BGP allows for the ALT to take advantage of BGP=0D
   security features designed for existing Internet BGP use.=0D
=0D
   For example, should either sBGP S-BGP [I-D.murphy-bgp-secr] or soBGP=0D
   [I-D.white-sobgparchitecture] become widely deployed it expected that=0D=

   LISP+ALT could use these mechanisms to provide authentication of EID-=0D=

   to-RLOC mappings, and EID origination.=0D
=0D
12.=0D
=0D
11.  Acknowledgments=0D
=0D
   Many=0D
=0D
   The authors would like to specially =
thank J. Noel Chiappa who was a=0D
   key contributer to the design of the LISP-CONS mapping database (many=0D
   ideas described in this document were =
developed during=0D
   detailed discussions with Scott Brim from which made their way into LISP+ALT) =
and Darrel Lewis, who =
made many=0D
   insightful comments on earlier versions of this document.=0D
=0D
13. has continued=0D
   to provide invaluable insight as the LISP effort has evolved.  Others=0D=

   who have provided valuable contributions include John Zwiebel, Hannu=0D=

   Flinck, Amit Jain, John Scudder, and Scott Brim.=0D
=0D
12.  References=0D
=0D
13.1.=0D
=0D
12.1.  Normative =
References=0D
=0D
   [RFC2119]  Bradner, S., "Key words for =
use=0D
=0D
   [LISP]     Farinacci, D., Fuller, V., =
Meyer, D., and D. Lewis,=0D
              "Locator/ID Separation Protocol (LISP)",=0D
              draft-ietf-lisp-06.txt (work in =
RFCs to Indicate=0D
              Requirement Levels", BCP 14, RFC 2119, March =
1997. progress), January =
2010.=0D
=0D
   [LISP-MS]  Fuller, V. and D. Farinacci, "LISP Map Server",=0D
              draft-ietf-lisp-ms-04.txt (work in progress),=0D
              October 2009.=0D
=0D
   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.=0D
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,=0D=

              March 2000.=0D
=0D
   [RFC2858]  Bates, T., Rekhter, Y., Chandra, R., and D. Katz,=0D
              "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.=0D=

=0D
   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway=0D
              Protocol 4 (BGP-4)", RFC 4271, January 2006.=0D
=0D
   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing=0D
              (CIDR): The Internet Address Assignment and Aggregation=0D
              Plan", BCP 122, RFC 4632, August 2006.=0D
=0D
13.2.=0D
=0D
12.2.  Informative =
References=0D
=0D
   [I-D.murphy-bgp-secr]=0D
              Murphy, S., "BGP Security Analysis",=0D
              draft-murphy-bgp-secr-04 (work in progress),=0D
              November 2001.=0D
=0D
   [I-D.white-sobgparchitecture]=0D
              White, R., "Architecture and Deployment Considerations for=0D=

              Secure Origin BGP (soBGP)",=0D
              draft-white-sobgparchitecture-00 (work in progress),=0D
              May 2004.=0D
=0D
   [LISP]     Farinacci,=0D
=0D
   [LISP-IW]  Lewis, D., =
Oran, Meyer, D., Farinacci, D., and V. Fuller, V.,=0D
              "Interworking LISP with =
IPv4 and D. Meyer,=0D
              "Locator/ID Separation Protocol (LISP)",=0D
              draft-farinacci-lisp-07.txt ipv6",=0D
              draft-ietf-lisp-interworking-02.txt (work =
in progress),=0D
              November 2007.=0D=

              February =
2010.=0D
=0D
Authors' Addresses=0D
=0D
   Dino Farinacci=0D
=0D
   Vince Fuller=0D
   Cisco=0D
   Tasman Drive=0D
   San Jose, CA  95134=0D
   USA=0D
=0D
   Email: dino@cisco.com=0D
=0D
   Vince Fuller vaf@cisco.com=0D
=0D
   Dino Farinacci=0D
   Cisco=0D
   Tasman Drive=0D
   San Jose, CA  95134=0D
   USA=0D
=0D
   Email: vaf@cisco.com =
dino@cisco.com=0D
=0D
   Dave Meyer=0D
   Cisco=0D
   Tasman Drive=0D
   San Jose, CA  95134=0D
   USA=0D
=0D
   Email: dmm@cisco.com=0D
=0D
Full Copyright Statement=0D
=0D
   Copyright (C) The IETF Trust (2008).=0D
=0D
   This document is subject to the rights, licenses and restrictions=0D
   contained in BCP 78, and except as set forth therein, the authors=0D
   retain all their rights.=0D
=0D
   This document and the information contained herein are provided on an=0D=

   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0D=

   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0D=

   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0D=

   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0D=

   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0D
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0D
=0D
Intellectual Property=0D
=0D
   The IETF takes no position regarding the validity or scope of any=0D
   Intellectual Property Rights or other rights that might be claimed to=0D=

   pertain to the implementation or use of the technology described in=0D=

   this document or the extent to which any license under such rights=0D
   might or might not be available; nor does it represent that it has=0D
   made any independent effort to identify any such rights.  Information=0D=

   on the procedures with respect to rights in RFC documents can be=0D
   found in BCP 78 and BCP 79.=0D
=0D
   Copies of IPR disclosures made to the IETF Secretariat and any=0D
   assurances of licenses to be made available, or the result of an=0D
   attempt made to obtain a general license or permission for the use of=0D=

   such proprietary rights by implementers or users of this=0D
   specification can be obtained from the IETF on-line IPR repository at=0D=

   http://www.ietf.org/ipr.=0D
=0D
   The IETF invites any interested party to bring to its attention any=0D=

   copyrights, patents or patent applications, or other proprietary=0D
   rights that may cover technology that may be required to implement=0D
   this standard.  Please address the information to the IETF at=0D
   ietf-ipr@ietf.org.=0D
=0D
   Darrel Lewis=0D
   Cisco=0D
   Tasman Drive=0D
   San Jose, CA  95134=0D
   USA=0D
=0D
   Email: darlewis@cisco.com=0D
=0D = --Apple-Mail-15-1057297310 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" > --Apple-Mail-15-1057297310-- From Adrian.Farrel@huawei.com Mon Mar 22 13:41:24 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A503A6A3B for ; Mon, 22 Mar 2010 13:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.409 X-Spam-Level: * X-Spam-Status: No, score=1.409 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_60=1, DNS_FROM_OPENWHOIS=1.13, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rO6yVLh0NLY for ; Mon, 22 Mar 2010 13:41:24 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 47FE63A69FC for ; Mon, 22 Mar 2010 13:41:23 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZP008RVATGW8@usaga01-in.huawei.com> for rtg-dir@ietf.org; Mon, 22 Mar 2010 13:41:40 -0700 (PDT) Received: from your029b8cecfe (dhcp-wireless-open-abg-25-211.meeting.ietf.org [130.129.25.211]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZP00AHYATES5@usaga01-in.huawei.com> for rtg-dir@ietf.org; Mon, 22 Mar 2010 13:41:40 -0700 (PDT) Date: Mon, 22 Mar 2010 20:40:58 +0000 From: Adrian Farrel To: Routing Area Directorate Message-id: <2BA75BE5717C43DC9ED834700A17F375@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Subject: [RTG-DIR] Beer (etc.) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 20:41:24 -0000 The best I have been able to find is to simply gather in the bar and grab an AD and insist that they give you beer. You can then gather in groups and complain about us. I'll be there from 8pm to 10pm CU Adrian From loa@pi.nu Mon Mar 22 14:22:06 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9663A6B60 for ; Mon, 22 Mar 2010 14:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.638 X-Spam-Level: * X-Spam-Status: No, score=1.638 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtDS9XLag+iG for ; Mon, 22 Mar 2010 14:22:05 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id DDB2F3A6BBE for ; Mon, 22 Mar 2010 14:18:18 -0700 (PDT) Received: from [130.129.25.89] (dhcp-wireless-open-abg-25-89.meeting.ietf.org [130.129.25.89]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id E6B46D4055 for ; Mon, 22 Mar 2010 22:18:34 +0100 (CET) Message-ID: <4BA7DEAA.9040809@pi.nu> Date: Mon, 22 Mar 2010 14:18:34 -0700 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: rtg-dir@ietf.org References: <2BA75BE5717C43DC9ED834700A17F375@your029b8cecfe> In-Reply-To: <2BA75BE5717C43DC9ED834700A17F375@your029b8cecfe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [RTG-DIR] Beer (etc.) X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 21:22:06 -0000 OK - I'll be there too, if there is an interest I can organize the group that will be complaining about Adrian ;), expect a written report! /Loa On 2010-03-22 13:40, Adrian Farrel wrote: > The best I have been able to find is to simply gather in the bar and > grab an AD and insist that they give you beer. > > You can then gather in groups and complain about us. > > I'll be there from 8pm to 10pm > > CU > Adrian -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From db3546@att.com Mon Mar 22 17:18:11 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DA428C27F for ; Mon, 22 Mar 2010 17:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.846 X-Spam-Level: X-Spam-Status: No, score=-105.846 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEQFcNKszz5q for ; Mon, 22 Mar 2010 17:18:10 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 9DA8728C283 for ; Mon, 22 Mar 2010 17:17:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: db3546@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1269303470!39844111!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 21932 invoked from network); 23 Mar 2010 00:17:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Mar 2010 00:17:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2N0Hd9Q003934 for ; Mon, 22 Mar 2010 20:17:39 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2N0HbKr003919 for ; Mon, 22 Mar 2010 20:17:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {F42858F5-9E74-439C-8D6D-14D281410B32} MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: BMD8 BMoy C3ts C6Hb G0cD KHWn KTei LSVz M8bL O1bz Py+0 QhNH QnOm Q+/5 TIxy VHHq; 2; ZABhAG4AbABpAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA7AHIAdABnAC0AZABpAHIAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {F42858F5-9E74-439C-8D6D-14D281410B32}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Tue, 23 Mar 2010 00:17:43 GMT; QgBhAGMAawB1AHAAIABSAG8AdQB0AGkAbgBnACAAQQByAGUAYQAgAEQAaQByAGUAYwB0AG8AcgBhAHQAZQAgAEMAbwBvAHIAZABpAG4AYQB0AG8AcgA= Content-class: urn:content-classes:message Date: Mon, 22 Mar 2010 20:17:43 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Backup Routing Area Directorate Coordinator Thread-Index: AcrKHkGD7WJm40+5QFeCF3nkDA1LDA== From: "BRUNGARD, DEBORAH A (ATTLABS)" To: Cc: Dan Li Subject: [RTG-DIR] Backup Routing Area Directorate Coordinator X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 00:18:11 -0000 Please welcome Dan Li as a Backup Routing Area Directorate Coordinator for me (so that I now can take vacation)- Deborah From vaf@cisco.com Mon Mar 22 22:16:53 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787863A67F4 for ; Mon, 22 Mar 2010 22:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, J_CHICKENPOX_43=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haZmxuwzAJqz for ; Mon, 22 Mar 2010 22:16:47 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 76BFE3A698F for ; Mon, 22 Mar 2010 22:16:38 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPbqp0urR7H+/2dsb2JhbACbKHOiZph+hH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,292,1267401600"; d="scan'208";a="104185928" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 23 Mar 2010 05:16:57 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2N5GviF028992; Tue, 23 Mar 2010 05:16:57 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id EB73A123C1C; Mon, 22 Mar 2010 22:17:06 -0700 (PDT) Date: Mon, 22 Mar 2010 22:17:06 -0700 From: Vince Fuller To: Ron Bonica Message-ID: <20100323051706.GA6331@vaf-mac1.cisco.com> References: <4B9E9A98.5060809@bonica.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B9E9A98.5060809@bonica.org> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Tue, 23 Mar 2010 08:02:05 -0700 Cc: rtg-dir@ietf.org, draft-ietf-lisp@tools.ietf.org, lisp@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] draft-ietf-lisp-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 05:16:53 -0000 Hello Ron- Thanks for the feedback. The LISP authors appreciate the opportunity to improve the qualify of our documents. I'll respond to each of the comments in turn. > Major Issues: > > o Architectural Issues > > - Tunnel Liveness - The document says little about what happens when a > tunnel connecting iTR to eTR fails? Does temporary black-holing result? > What is the restoration mechanism? Please re-read section 6.3, titled titled "Routing Locator Reachability" which covers maintenance of ITR to ETR state. While LISP does perform encapsulation and is thus conceptually a tunneling protocol (hence the terms "Ingress Tunnel Router" and "Egress Tunnel Router", there is no explicit tunnel state so your question should perhaps be re- phrased as "what happens when an ITR loses connectivity to an ETR RLOC?". > - UDP Checksum - When an iTR formats the LISP UDP header, it sets the > UDP checksum to zero. This is in violation of RFC 768. RFC 768 does not prohibit zero IP UDP checksums, which are in common use by a number of protocols (NFS comes to mind), so this comment would seem to be in error. There are open issues with zero UDP checksums for ipv6, but not only are those issues beyond the scope of RFC 768 (which predates ipv6 by many years) but they also affect a number of other protocols other than LISP (AMT et al) and are being discussed in a larger context (MBONED, et al. Please see Joel Halpern's recent message on this topic fo the lisp@ietf.org mailing list. > - The document should say something about cases in which NATs and middle > boxes are deployed between iTR and ETR. Will those boxes continue to work? This is an implementation and configuration issue and is beyond the scope of this protocol description. Testing on our pilot network has verified that LISP works through NAT boxes, though how that is configured is implementation- specific. This topic will also be the topic of a forthcoming LISP Deployment document that has been discussed on the lisp@ietf.org. The Interworking draft also has some descriptive text regarding NAT and LISP. > o Caching Issues > > - The caching policy is not well specified. Therefore, I am worried that > the cache might become an easy target for DoS attacks. Consider the > following scenario: > > An opponent discovers the EIDs of 100 hosts behind an ITR. The opponent > then sends a steady stream of 50 pps to each of those 100 hosts. Each of > those packets has a unique, valid and spoofed source address. Each > packet also causes its recipient to send an ICMP port unreachable > message to the spoofed source. The ITR cache may be overrun. This is an implementation issue that is beyond the scope of this protocol specification. Other common protocols, including ARP and DNS, have similar vulnerabilities and Well-known rate-limiting and other mechanisms exist for ameliorating the damage caused by such cache-pollution attacks. LISP implementations would be advised to incorporate such mechanisms. > o Migration issues Considerations > > - During the migration period, when an ITR receives a packet, it must > determine whether that packet's destination address is an EID or an > RLOC. The document isn't clear about how the ITR does this. One > possibility is to encode that information in the IP address. Another is > to query the network to find out. While the first solution may work for > IPv6, it won't work well for IPv4. The second solution presents > performance problems regardless of IP version. This is an interworking issue and is beyond the scope of this protocol implementation. Please refer to the LISP Map Server specification for discussion of how an ITR determines whether a destination IP address is an EID or a legacy, non-LISP address. The LISP+ALT specification also documents how the EID-to- RLOC database is used to make this determination and the LISP Interworking covers, in detail, the mechanisms for LISP and non-LISP sites to communicate. > - LISP's goals are best achieved when the entire Internet is surrounded > by xTRs (i.e., at the end of migration). However, it is impossible to > know when that state has been achieved. The document should say > something about when an operator has completed its migration effort and > what benefit it can expect to reap at that time. This comment would seem to be beyond the scope of this protocol specification. Not only does LISP offer a long-term strategy for reducing the growth of global Internet routing state but it also offers short-term benefits for early adopters, including simplar site multihoming that also offers new traffic engineering capabilities. Migration would also seem to be a central topic of a future LISP Deployment document. > Minor Issues > > - Terminology section defines many terms that are already commonly > understood. Given how much confusion has persisted on the RRG and lisp@ietf.org mailing lists about such "commonly understood" terms as "Endpoint ID" and "Locator", the LISP authors decided to err on the side of redundancy in defining terms. > Nits: > > > == You're using the IETF Trust Provisions' Section 6.b License Notice from > 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See > http://trustee.ietf.org/license-info/) This should be automatically fixed when the xml2rfc template is updated. > ** The document seems to lack an IANA Considerations section. I don't believe this document is asking for any new IANA assignments since LISP already has the protocol identifiers (UDP port numbers) that it needs. > ** There are 5 instances of lines with non-RFC2606-compliant FQDNs in > the document. Can you please list the specific errors so that we can fix them? > > == There are 10 instances of lines with private range IPv4 addresses > in the document. If these are generic example addresses, they should be > changed to use any of the ranges defined in RFC3330 (or successor): > 192.0.2.x, 198.51.100.x or 203.0.113.x. Unfortunately, RFC3330 space is too small to use for some of the examples contained in the LISP documents (LISP+ALT suffers from this nit as well). For this reason, we have chosen to use RFC1918 space in our examples. > Miscellaneous warnings: > > ---------------------------------------------------------------------------- > > == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', > or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please > use uppercase 'NOT' together with RFC 2119 keywords (if that is what you > mean). Can you please list the specific errors so that we can fix them? > > Found 'MUST not' in this paragraph: > > LCM: The format is one of the control message formats described > in this section. At this time, only Map-Request messages and PIM > Join-Prune messages [MLISP] are allowed to be encapsulated. > Encapsulating > other types of LISP control messages are for further study. When > Map-Requests are sent for RLOC-probing purposes (i.e the P-bit is set), > they MUST not be sent inside Encapsulated Control Messages. We will fix this, thanks. > Checking references for intended status: Experimental > > ---------------------------------------------------------------------------- > > ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) > > == Outdated reference: A later version (-02) exists of draft-jen-apt-01 > > == Outdated reference: A later version (-05) exists of > draft-meyer-lisp-cons-03 > > -- Unexpected draft version: The latest known version of > draft-ietf-lisp-interworking is -00, but you're referring to -01. > > == Outdated reference: A later version (-02) exists of > draft-farinacci-lisp-lig-01 > > == Outdated reference: A later version (-01) exists of > draft-meyer-lisp-mn-00 > > == Outdated reference: A later version (-04) exists of > draft-ietf-lisp-ms-03 > > -- No information found for draft-mathy-lisp-dht - is the name correct? > > == Outdated reference: A later version (-08) exists of > draft-lear-lisp-nerd-04 > > == Outdated reference: A later version (-02) exists of > draft-iannone-openlisp-implementation-01 > > == Outdated reference: A later version (-05) exists of > draft-narten-radir-problem-statement-00 > > == Outdated reference: A later version (-09) exists of > draft-ietf-mip4-rfc3344bis-05 > > == Outdated reference: draft-ietf-pim-rpf-vector has been published as RFC > 5496 > > -- No information found for draft-handley-p2ppush-unpublished-2007726 - is > the name correct? > > == Outdated reference: draft-ietf-shim6-proto has been published as > RFC 5533 We will fix the outdated references, thanks. --Vince From thomas@thomasclausen.org Tue Mar 23 14:50:16 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10D23A6C3D for ; Tue, 23 Mar 2010 14:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLYD6hbph2bP for ; Tue, 23 Mar 2010 14:50:15 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 8DDB93A6BF4 for ; Tue, 23 Mar 2010 14:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 66E1632356B5; Tue, 23 Mar 2010 14:50:35 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.27.171.249] (207.88.181.2.ptr.us.xo.net [207.88.181.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 220B53228088; Tue, 23 Mar 2010 14:50:35 -0700 (PDT) Message-Id: From: Thomas Heide Clausen To: Stig Venaas In-Reply-To: <4B957A8C.6020404@venaas.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 23 Mar 2010 22:50:34 +0100 References: <4B957A8C.6020404@venaas.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 23 Mar 2010 18:04:48 -0700 Cc: manet-chairs@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-manet-nhdp@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-manet-nhdp-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:50:17 -0000 Dear Stig, Thank you for your review. We have updated the document to accommodate your remarks, and expect to submit this shortly. Please see below for detailed comments to your review. On Mar 8, 2010, at 23:30 PM, Stig Venaas wrote: > 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-manet-nhdp-11.txt > Reviewer: Stig Venaas > Review Date: March 8, 2010 > IETF LC End Date: Unknown > Intended Status: Standards Track > > Summary: > > The document is well written and I see no major issues with the > specification. Although the first minor issue may be important, > but I may be missing something. There are also some minor concerns > like message size and interoperability. > > Minor Issues: > > In S4.1: > Each MANET interface: > > o Is configured with one or more network addresses. All addresses > represented by these network addresses MUST be unique to this > router at least within its 2-hop neighborhood. All such > addresses > MUST be unique to this MANET interface, except that an address > can > be used by more than one MANET interface on the same router if > those MANET interfaces are "isolated" from each other (no MANET > interface on another router can hear or be heard by two MANET > interfaces using overlapping network addresses). > > This definition seems less strict than what is in last paragraph of 6 > (right before 6.1). That says also "one to and one from". Done - we have tightened 4.1 to be in line with section 6, both in content and in style. > I'm wondering if this definition is strict enough. Do you want to > allow > a topology like the below where there are two links connecting > neighbors > A and B where A uses the same address "a" on both links? > > a -- > A B -- C > a -- The answer to the above is "it depends": if B has a single interface, then this configuration is prohibited by the text above (section 6 and section 4.1). If B has two different interfaces, each of which "sees only one of a, but not both", then it is an allowed configuration because "it works" (there would be, for an interface of b, be no ambiguity of which "a" was heard). > Wouldn't then B send messages to C containing "a" twice? Would that be > correctly processed by C? Wouldn't C basically treat them as the same > announcement twice. No. Section 11.1, numbered bullet point 2 precludes this by the "...and which has not already been included..." test-clause for inclusion. B would send it once, and C would process them correctly. > And if say one of them is removed, remove both until > the next update? If B has two interfaces (the allowable configuration above), and one of the "a" is removed from A, then the link set for the corresponding interface of B would reflect this. The neighbor set of B would still record "a" as a neighbor (which it would be via the other interface of B). In other words, the protocol would handle this situation correctly. > In S5.1: > This protocol specifies HELLO messages, which are included in > packets > as defined by [RFC5444]. These packets may be sent either using the > "manet" protocol number or the "manet" well-known UDP port number, > as > specified in [RFC5498]. > > Should implementations listen for both? Should it be configurable > which > one to listen too? Are there possible interoperability issues? NHDP will operate correctly over either. RFC5498 leaves the option of which to chose (either or both) open. It is the authors opinion that a deployment would chose to run either over an UDP port number or over a protocol number (but not both concurrently, although nothing in this protocol specification would preclude correct operation also in this case). A slightly more complete answer is, that there were some members in the WG expressing a preference for using an UDP port, and some other members preferring using protocol numbers, for when running [MANET] protocols -- and RFC5498 was published without arbitrating this issue. As this protocol runs as an instance of RFC5444, this is furthermore not an issue that NHDP can address in isolation. > > In S9.3 > 2. Any Neighbor Tuples whose N_neighbor_addr_list contains the > added > network address, are removed. > > Is it OK if it contains an overlapping address? That is if some Tuple > has a N_neighbor_addr_list with an element that overlaps this address, > or vice versa. Done. Very good catch, thanks! Section 9.3 had some lingering wording surviving from before the "contains" and "overlapping" terminology was introduced -- we have adapted 9.3 to clean this up. > > In S11.1: > > If any such network addresses have been added to these Information > Bases since the last HELLO message was sent on this MANET interface, > or if their status (as indicated by these TLVs and the Values they > associate with that network address) have changed since that network > address was last reported on this MANET interface, then that network > address, and the indicated TLVs, MUST be included in the HELLO > message. > > May not this be too much to fit in a single message? > > The document should perhaps discuss whether messages should be within > the link MTU? Or is fragmentation OK? Is it better to send a large > Hello > (which may be fragmented) to get new information out fast than to > split > the info in different Hellos? In general when the info is not changed, > then I assume it should be split. But if a router has many local > addresses to include, then more bandwidth is used with multiple > hello's > compared to a single large fragmented one. At least I think some > considerations/discussion would be good. Done. We have (i) changed the MUST to SHOULD and (ii) added an explanatory paragraph addressing the issue you mention above. > Nits: > > Definition of Network Address in Section 2: > > Network Address An address plus an associated prefix length. This > ^^^ > missing - Done. > The definition of Heard in Section 2 is: > Heard - A MANET interface of router X is considered heard on a > MANET > interface of a router Y if the latter can receive traffic from > the > former. > > I'm not sure what "traffic" is here. As in receiving Hello messages? > Maybe there is a more precise term? Done. Good point - we addressed it by replacing "traffic" by "control messages, according to this specification," in order to avoid forward- references, as at this point in the specification "HELLO messages" have not yet been introduced or defined. > Definition in Section 2: c = d is a comparison operator > > Might it be better for unordered lists to define it as "c contains d > and > d contains c"? And for addresses as, "c overlaps d and d overlaps c"? For unordered lists, agreed -- and done. For addresses, the "overlaps" operator is symmetric, i.e., if "c overlaps d" then it is always true that "d overlaps c" -- and so this cannot be used for defining equality. We have therefore retained the original text on this point. > End of S4.2: > received in a HELLO message is considered valid. Appendix F > illustrates some example two hop topologies and how they correspond > Two-hop? ^^^^^^^ > to information in the Information Bases. Done. Removed "two hop" and retained "... some example topologies and how they correspond ...." However, as a follow-on from this issue, we have rendered consistent "2-hop" and "1-hop" usage (there were a couple of lingering "two hop" and "one hop" mentions left). > In S4.3.2 > corresponding Link Set and the Neighbor Information Base. Note > that when determining whether to include information in a HELLO > message, the sender MUST consider all times up to the latest time > when it may send its next HELLO message on this MANET interface. > > What does this mean? Can it be formulated more clearly? I can guess, > but > it's at best unclear. Duly noted -- tt's difficult to be both concise and clear at the same time on this. We have tried to rewrite that paragraph -- hoping that it is clearer (albeit a bit more verbose) in the new version > > In S7.1: > L_HEARD_time is the time until which the MANET interface of the > 1-hop neighbor would be considered heard if not considering link > quality; > > I guess this means it is heard until L_HEARD_time expires, but I think > it may be read as "time until it would become heard". That after > waiting > L_HEARD_time, it will be considered heard. Maybe this could be > formulated in a less confusing way? Say "time for which" would for > me be > much clearer than "time until which". I'm not a native English speaker > though, but it will be read by many other non-native speakers as well. > > This may apply to other places where it says "time until which" too. We cannot say "the time for which" as that would imply an interval, whereas "the time until which" refers to an exact instance (moment) of time in the future. The best alternative we have been able to come up with is "the time up to which" - in your opinion, is that clearer? > In S9: > the the Interface Information Base and the Neighbor Information Base. > ^^^^^^ Done (outch). > In S12.1: > o The address length as specified in the Message Header is not > equal > to the length of the addresses used by this router. > > Shouldn't this be worded differently for a router supporting both IPv4 > and IPv6, that is, the router uses addresses of multiple lengths. We have discussed this in great detail. The bottom line is, that mixed- mode operation is a complicated beast -- notably, how would an IPv4- aware router deal with receiving a HELLO message containing IPv6 addresses (and how would an IPv4 router send HELLO messages containing both IPv4 and IPv6 addresses, not knowing how to map v4 to v6). The "obvious way of doing it" might just work fine by "not breaking NHDP" -- but cause fundamentally useless information to be propagated among the NHDP routers (and, possibly, used by whatever other protocols interacting with NHDP). We prefer to keep the restriction as is stated above: pick an address family (we recommend v6 :-) ), and stick with it. Should a need for mixed-mode operation arise, a protocol extension to NHDP can be developed, lifting that restriction (and likely engaging in also how to do proper v6-v4 NAT etc). We believe that having a restriction in place causing routers *not* implementing such an extension to reject participating in a mixed- family network to be the safer approach. Mange takk for din hjelp, Stig, Thomas > > Stig From rbonica@juniper.net Fri Mar 26 14:40:06 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48FC43A6A92 for ; Fri, 26 Mar 2010 14:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.969 X-Spam-Level: X-Spam-Status: No, score=-99.969 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_43=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raUna5yxBmag for ; Fri, 26 Mar 2010 14:40:04 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id BAD553A67D3 for ; Fri, 26 Mar 2010 14:39:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS60pwCDJSvVwRbxyUsCOR+fRG6mcW827@postini.com; Fri, 26 Mar 2010 14:40:21 PDT Received: from [172.28.134.16] (172.28.134.16) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 26 Mar 2010 14:39:14 -0700 Message-ID: <4BAD297D.4090906@juniper.net> Date: Fri, 26 Mar 2010 17:39:09 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Vince Fuller References: <4B9E9A98.5060809@bonica.org> <20100323051706.GA6331@vaf-mac1.cisco.com> In-Reply-To: <20100323051706.GA6331@vaf-mac1.cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-lisp@tools.ietf.org, lisp@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] draft-ietf-lisp-06.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 21:40:06 -0000 Hi Vince, Responses inline.... Vince Fuller wrote: > Hello Ron- > > Thanks for the feedback. The LISP authors appreciate the opportunity to > improve the qualify of our documents. > > I'll respond to each of the comments in turn. > >> Major Issues: >> >> o Architectural Issues >> >> - Tunnel Liveness - The document says little about what happens when a >> tunnel connecting iTR to eTR fails? Does temporary black-holing result? >> What is the restoration mechanism? > > Please re-read section 6.3, titled titled "Routing Locator Reachability" > which covers maintenance of ITR to ETR state. I can think of situations in which none of the mechanisms described in 6.3 would kick in in a timely manner. For example, assume that there is a five-hop path between the iTR and eTR. The path is working just fine, until somebody configures an ACL on hop 3 that silently discards packets. Which protection kicks in and how long does it take? > > While LISP does perform encapsulation and is thus conceptually a tunneling > protocol (hence the terms "Ingress Tunnel Router" and "Egress Tunnel Router", > there is no explicit tunnel state so your question should perhaps be re- > phrased as "what happens when an ITR loses connectivity to an ETR RLOC?". I think that I understand what happens when the iTR realizes that it has lost connectivity to the eTR. My question is, does the iTR reliably realize this in a timely manner. > >> - UDP Checksum - When an iTR formats the LISP UDP header, it sets the >> UDP checksum to zero. This is in violation of RFC 768. > > RFC 768 does not prohibit zero IP UDP checksums, which are in common use by > a number of protocols (NFS comes to mind), so this comment would seem to be > in error. There are open issues with zero UDP checksums for ipv6, but not > only are those issues beyond the scope of RFC 768 (which predates ipv6 by > many years) but they also affect a number of other protocols other than LISP > (AMT et al) and are being discussed in a larger context (MBONED, et al. > > Please see Joel Halpern's recent message on this topic fo the lisp@ietf.org > mailing list. I stand corrected and would like to repeat Joel's question regarding UDP checksums and IPv6. > >> - The document should say something about cases in which NATs and middle >> boxes are deployed between iTR and ETR. Will those boxes continue to work? > > This is an implementation and configuration issue and is beyond the scope > of this protocol description. Testing on our pilot network has verified that > LISP works through NAT boxes, though how that is configured is implementation- > specific. > > This topic will also be the topic of a forthcoming LISP Deployment document > that has been discussed on the lisp@ietf.org. The Interworking draft also > has some descriptive text regarding NAT and LISP. If another document is coming, I can accept that. > >> o Caching Issues >> >> - The caching policy is not well specified. Therefore, I am worried that >> the cache might become an easy target for DoS attacks. Consider the >> following scenario: >> >> An opponent discovers the EIDs of 100 hosts behind an ITR. The opponent >> then sends a steady stream of 50 pps to each of those 100 hosts. Each of >> those packets has a unique, valid and spoofed source address. Each >> packet also causes its recipient to send an ICMP port unreachable >> message to the spoofed source. The ITR cache may be overrun. > > This is an implementation issue that is beyond the scope of this protocol > specification. Other common protocols, including ARP and DNS, have similar > vulnerabilities and Well-known rate-limiting and other mechanisms exist for > ameliorating the damage caused by such cache-pollution attacks. LISP > implementations would be advised to incorporate such mechanisms. I don't think that this response is acceptable. The scaling requirements of the lisp cache are very different from those of ARP and DNS. So are the consequences of cache overrun. In order to demonstrate that this experiment doesn't present a risk to the Internet, I would discuss this topic in more depth. > >> o Migration issues Considerations >> >> - During the migration period, when an ITR receives a packet, it must >> determine whether that packet's destination address is an EID or an >> RLOC. The document isn't clear about how the ITR does this. One >> possibility is to encode that information in the IP address. Another is >> to query the network to find out. While the first solution may work for >> IPv6, it won't work well for IPv4. The second solution presents >> performance problems regardless of IP version. > > This is an interworking issue and is beyond the scope of this protocol > implementation. > > Please refer to the LISP Map Server specification for discussion of how > an ITR determines whether a destination IP address is an EID or a legacy, > non-LISP address. The LISP+ALT specification also documents how the EID-to- > RLOC database is used to make this determination and the LISP Interworking > covers, in detail, the mechanisms for LISP and non-LISP sites to > communicate. ok > >> - LISP's goals are best achieved when the entire Internet is surrounded >> by xTRs (i.e., at the end of migration). However, it is impossible to >> know when that state has been achieved. The document should say >> something about when an operator has completed its migration effort and >> what benefit it can expect to reap at that time. > > This comment would seem to be beyond the scope of this protocol specification. > Not only does LISP offer a long-term strategy for reducing the growth of > global Internet routing state but it also offers short-term benefits for > early adopters, including simplar site multihoming that also offers new > traffic engineering capabilities. > > Migration would also seem to be a central topic of a future LISP Deployment > document. OK. If another document is coming, that's fine. > >> Minor Issues >> >> - Terminology section defines many terms that are already commonly >> understood. > > Given how much confusion has persisted on the RRG and lisp@ietf.org > mailing lists about such "commonly understood" terms as "Endpoint ID" > and "Locator", the LISP authors decided to err on the side of redundancy > in defining terms. > >> Nits: >> >> >> == You're using the IETF Trust Provisions' Section 6.b License Notice from >> 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See >> http://trustee.ietf.org/license-info/) > > This should be automatically fixed when the xml2rfc template is updated. > >> ** The document seems to lack an IANA Considerations section. > > I don't believe this document is asking for any new IANA assignments since > LISP already has the protocol identifiers (UDP port numbers) that it needs. > >> ** There are 5 instances of lines with non-RFC2606-compliant FQDNs in >> the document. > > Can you please list the specific errors so that we can fix them? I have no idea what the errors were. This list was generated by the automated tool. > >> == There are 10 instances of lines with private range IPv4 addresses >> in the document. If these are generic example addresses, they should be >> changed to use any of the ranges defined in RFC3330 (or successor): >> 192.0.2.x, 198.51.100.x or 203.0.113.x. > > Unfortunately, RFC3330 space is too small to use for some of the examples > contained in the LISP documents (LISP+ALT suffers from this nit as well). > For this reason, we have chosen to use RFC1918 space in our examples. > >> Miscellaneous warnings: >> >> ---------------------------------------------------------------------------- >> >> == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', >> or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please >> use uppercase 'NOT' together with RFC 2119 keywords (if that is what you >> mean). > > Can you please list the specific errors so that we can fix them? >> Found 'MUST not' in this paragraph: >> >> LCM: The format is one of the control message formats described >> in this section. At this time, only Map-Request messages and PIM >> Join-Prune messages [MLISP] are allowed to be encapsulated. >> Encapsulating >> other types of LISP control messages are for further study. When >> Map-Requests are sent for RLOC-probing purposes (i.e the P-bit is set), >> they MUST not be sent inside Encapsulated Control Messages. > > We will fix this, thanks. > >> Checking references for intended status: Experimental >> >> ---------------------------------------------------------------------------- >> >> ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) >> >> == Outdated reference: A later version (-02) exists of draft-jen-apt-01 >> >> == Outdated reference: A later version (-05) exists of >> draft-meyer-lisp-cons-03 >> >> -- Unexpected draft version: The latest known version of >> draft-ietf-lisp-interworking is -00, but you're referring to -01. >> >> == Outdated reference: A later version (-02) exists of >> draft-farinacci-lisp-lig-01 >> >> == Outdated reference: A later version (-01) exists of >> draft-meyer-lisp-mn-00 >> >> == Outdated reference: A later version (-04) exists of >> draft-ietf-lisp-ms-03 >> >> -- No information found for draft-mathy-lisp-dht - is the name correct? >> >> == Outdated reference: A later version (-08) exists of >> draft-lear-lisp-nerd-04 >> >> == Outdated reference: A later version (-02) exists of >> draft-iannone-openlisp-implementation-01 >> >> == Outdated reference: A later version (-05) exists of >> draft-narten-radir-problem-statement-00 >> >> == Outdated reference: A later version (-09) exists of >> draft-ietf-mip4-rfc3344bis-05 >> >> == Outdated reference: draft-ietf-pim-rpf-vector has been published as RFC >> 5496 >> >> -- No information found for draft-handley-p2ppush-unpublished-2007726 - is >> the name correct? >> >> == Outdated reference: draft-ietf-shim6-proto has been published as >> RFC 5533 > > We will fix the outdated references, thanks. > > --Vince > > From stig@venaas.com Tue Mar 30 10:04:44 2010 Return-Path: X-Original-To: rtg-dir@core3.amsl.com Delivered-To: rtg-dir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96183A67B2 for ; Tue, 30 Mar 2010 10:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.831 X-Spam-Level: ** X-Spam-Status: No, score=2.831 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi6+VaDv0gwj for ; Tue, 30 Mar 2010 10:04:43 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by core3.amsl.com (Postfix) with ESMTP id 31A843A67CF for ; Tue, 30 Mar 2010 10:04:35 -0700 (PDT) Received: from [10.32.214.38] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTP id 1F37B224B8; Tue, 30 Mar 2010 19:05:01 +0200 (CEST) Message-ID: <4BB22F3B.6030104@venaas.com> Date: Tue, 30 Mar 2010 10:04:59 -0700 From: Stig Venaas User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4B957A8C.6020404@venaas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: manet-chairs@tools.ietf.org, rtg-dir@ietf.org, draft-ietf-manet-nhdp@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-manet-nhdp-11.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 17:04:45 -0000 Hi Thomas Heide Clausen wrote: > Dear Stig, > > Thank you for your review. We have updated the document to accommodate > your remarks, and expect to submit this shortly. > > Please see below for detailed comments to your review. OK, please see my comments below then. > On Mar 8, 2010, at 23:30 PM, Stig Venaas wrote: > >> 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-manet-nhdp-11.txt >> Reviewer: Stig Venaas >> Review Date: March 8, 2010 >> IETF LC End Date: Unknown >> Intended Status: Standards Track >> >> Summary: >> >> The document is well written and I see no major issues with the >> specification. Although the first minor issue may be important, >> but I may be missing something. There are also some minor concerns >> like message size and interoperability. >> >> Minor Issues: >> >> In S4.1: >> Each MANET interface: >> >> o Is configured with one or more network addresses. All addresses >> represented by these network addresses MUST be unique to this >> router at least within its 2-hop neighborhood. All such addresses >> MUST be unique to this MANET interface, except that an address can >> be used by more than one MANET interface on the same router if >> those MANET interfaces are "isolated" from each other (no MANET >> interface on another router can hear or be heard by two MANET >> interfaces using overlapping network addresses). >> >> This definition seems less strict than what is in last paragraph of 6 >> (right before 6.1). That says also "one to and one from". > > Done - we have tightened 4.1 to be in line with section 6, both in > content and in style. Good >> I'm wondering if this definition is strict enough. Do you want to allow >> a topology like the below where there are two links connecting neighbors >> A and B where A uses the same address "a" on both links? >> >> a -- >> A B -- C >> a -- > > The answer to the above is "it depends": if B has a single interface, > then this configuration is prohibited by the text above (section 6 and > section 4.1). If B has two different interfaces, each of which "sees > only one of a, but not both", then it is an allowed configuration > because "it works" (there would be, for an interface of b, be no > ambiguity of which "a" was heard). > >> Wouldn't then B send messages to C containing "a" twice? Would that be >> correctly processed by C? Wouldn't C basically treat them as the same >> announcement twice. > > No. Section 11.1, numbered bullet point 2 precludes this by the "...and > which has not already been included..." test-clause for inclusion. B > would send it once, and C would process them correctly. Ah, of course! >> And if say one of them is removed, remove both until >> the next update? > > If B has two interfaces (the allowable configuration above), and one of > the "a" is removed from A, then the link set for the corresponding > interface of B would reflect this. The neighbor set of B would still > record "a" as a neighbor (which it would be via the other interface of B). > > In other words, the protocol would handle this situation correctly. Thanks, got it. >> In S5.1: >> This protocol specifies HELLO messages, which are included in packets >> as defined by [RFC5444]. These packets may be sent either using the >> "manet" protocol number or the "manet" well-known UDP port number, as >> specified in [RFC5498]. >> >> Should implementations listen for both? Should it be configurable which >> one to listen too? Are there possible interoperability issues? > > NHDP will operate correctly over either. RFC5498 leaves the option of > which to chose (either or both) open. It is the authors opinion that a > deployment would chose to run either over an UDP port number or over a > protocol number (but not both concurrently, although nothing in this > protocol specification would preclude correct operation also in this case). > > A slightly more complete answer is, that there were some members in the > WG expressing a preference for using an UDP port, and some other members > preferring using protocol numbers, for when running [MANET] protocols -- > and RFC5498 was published without arbitrating this issue. > > As this protocol runs as an instance of RFC5444, this is furthermore not > an issue that NHDP can address in isolation. OK >> >> In S9.3 >> 2. Any Neighbor Tuples whose N_neighbor_addr_list contains the added >> network address, are removed. >> >> Is it OK if it contains an overlapping address? That is if some Tuple >> has a N_neighbor_addr_list with an element that overlaps this address, >> or vice versa. > > Done. Very good catch, thanks! Section 9.3 had some lingering wording > surviving from before the "contains" and "overlapping" terminology was > introduced -- we have adapted 9.3 to clean this up. Looks good now. >> >> In S11.1: >> >> If any such network addresses have been added to these Information >> Bases since the last HELLO message was sent on this MANET interface, >> or if their status (as indicated by these TLVs and the Values they >> associate with that network address) have changed since that network >> address was last reported on this MANET interface, then that network >> address, and the indicated TLVs, MUST be included in the HELLO >> message. >> >> May not this be too much to fit in a single message? >> >> The document should perhaps discuss whether messages should be within >> the link MTU? Or is fragmentation OK? Is it better to send a large Hello >> (which may be fragmented) to get new information out fast than to split >> the info in different Hellos? In general when the info is not changed, >> then I assume it should be split. But if a router has many local >> addresses to include, then more bandwidth is used with multiple hello's >> compared to a single large fragmented one. At least I think some >> considerations/discussion would be good. > > > Done. We have (i) changed the MUST to SHOULD and (ii) added an > explanatory paragraph addressing the issue you mention above. New text looks reasonable. >> Nits: >> >> Definition of Network Address in Section 2: >> >> Network Address An address plus an associated prefix length. This >> ^^^ >> missing - > > Done. > >> The definition of Heard in Section 2 is: >> Heard - A MANET interface of router X is considered heard on a MANET >> interface of a router Y if the latter can receive traffic from the >> former. >> >> I'm not sure what "traffic" is here. As in receiving Hello messages? >> Maybe there is a more precise term? > > Done. Good point - we addressed it by replacing "traffic" by "control > messages, according to this specification," in order to avoid > forward-references, as at this point in the specification "HELLO > messages" have not yet been introduced or defined. Good. >> Definition in Section 2: c = d is a comparison operator >> >> Might it be better for unordered lists to define it as "c contains d and >> d contains c"? And for addresses as, "c overlaps d and d overlaps c"? > > For unordered lists, agreed -- and done. > > For addresses, the "overlaps" operator is symmetric, i.e., if "c > overlaps d" then it is always true that "d overlaps c" -- and so this > cannot be used for defining equality. We have therefore retained the > original text on this point. You are right of course :) > >> End of S4.2: >> received in a HELLO message is considered valid. Appendix F >> illustrates some example two hop topologies and how they correspond >> Two-hop? ^^^^^^^ >> to information in the Information Bases. > > Done. Removed "two hop" and retained "... some example topologies and > how they correspond ...." > > However, as a follow-on from this issue, we have rendered consistent > "2-hop" and "1-hop" usage (there were a couple of lingering "two hop" > and "one hop" mentions left). > >> In S4.3.2 >> corresponding Link Set and the Neighbor Information Base. Note >> that when determining whether to include information in a HELLO >> message, the sender MUST consider all times up to the latest time >> when it may send its next HELLO message on this MANET interface. >> >> What does this mean? Can it be formulated more clearly? I can guess, but >> it's at best unclear. > > Duly noted -- tt's difficult to be both concise and clear at the same > time on this. We have tried to rewrite that paragraph -- hoping that it > is clearer (albeit a bit more verbose) in the new version Yes, it became rather verbose, but should be clear now. >> >> In S7.1: >> L_HEARD_time is the time until which the MANET interface of the >> 1-hop neighbor would be considered heard if not considering link >> quality; >> >> I guess this means it is heard until L_HEARD_time expires, but I think >> it may be read as "time until it would become heard". That after waiting >> L_HEARD_time, it will be considered heard. Maybe this could be >> formulated in a less confusing way? Say "time for which" would for me be >> much clearer than "time until which". I'm not a native English speaker >> though, but it will be read by many other non-native speakers as well. >> >> This may apply to other places where it says "time until which" too. > > We cannot say "the time for which" as that would imply an interval, > whereas "the time until which" refers to an exact instance (moment) of > time in the future. > > The best alternative we have been able to come up with is "the time up > to which" - in your opinion, is that clearer? Yes, that is clearer, and also much better than my suggestion. > >> In S9: >> the the Interface Information Base and the Neighbor Information Base. >> ^^^^^^ > > Done (outch). > >> In S12.1: >> o The address length as specified in the Message Header is not equal >> to the length of the addresses used by this router. >> >> Shouldn't this be worded differently for a router supporting both IPv4 >> and IPv6, that is, the router uses addresses of multiple lengths. > > We have discussed this in great detail. The bottom line is, that > mixed-mode operation is a complicated beast -- notably, how would an > IPv4-aware router deal with receiving a HELLO message containing IPv6 > addresses (and how would an IPv4 router send HELLO messages containing > both IPv4 and IPv6 addresses, not knowing how to map v4 to v6). The > "obvious way of doing it" might just work fine by "not breaking NHDP" -- > but cause fundamentally useless information to be propagated among the > NHDP routers (and, possibly, used by whatever other protocols > interacting with NHDP). > > We prefer to keep the restriction as is stated above: pick an address > family (we recommend v6 :-) ), and stick with it. Should a need for > mixed-mode operation arise, a protocol extension to NHDP can be > developed, lifting that restriction (and likely engaging in also how to > do proper v6-v4 NAT etc). > > We believe that having a restriction in place causing routers *not* > implementing such an extension to reject participating in a mixed-family > network to be the safer approach. OK > Mange takk for din hjelp, Stig, :) Rev 12 looks good to me then, Stig > Thomas > >> >> Stig