idnits 2.17.1 

draft-bala-mplamps-04.txt:
  ** The Abstract section seems to be numbered


  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  == The page length should not exceed 58 lines per page, but there was 5
     longer pages, the longest (page 2) being 59 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  ** There are 2 instances of too long lines in the document, the longest one
     being 2 characters in excess of 72.

  ** The abstract seems to contain references ([2]), which it shouldn't. 
     Please replace those with straight textual mentions of the documents in
     question.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords -- however, there's a paragraph with a matching beginning.
     Boilerplate error?

     RFC 2119 keyword, line 60: '...on pre-requisite MUST be present in an...'
     RFC 2119 keyword, line 68: '...ent included), it may be REQUIRED that...'
     RFC 2119 keyword, line 105: '...le "foo-over-MPLS" draft SHOULD have a...'
     RFC 2119 keyword, line 209: '...ical details. Readers MUST satisfy the...'
     RFC 2119 keyword, line 306: '...ery foo-over-MPLS draft SHOULD lay the...'
     (2 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- Couldn't find a document date in the document -- date freshness check
     skipped.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? '1' on line 12 looks like a reference

  -- Missing reference section? '2' on line 35 looks like a reference

  -- Missing reference section? '3' on line 214 looks like a reference

  -- Missing reference section? '4' on line 316 looks like a reference


     Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Internet Draft                                         Bala Rajagopalan
3	Document: <draft-bala-mplamps-04.txt>                     Tellium, Inc.
4	This draft expires on August, 25, 2002

6	       MPLampS: Electricity over IP (with an MPLS control plane)

8	Status of this Memo

10	   This document is an Internet-Draft and is in full conformance with
11	   all provisions of Section 10 of RFC2026 [1].

13	   Internet-Drafts are working documents of the Internet Engineering
14	   Task Force (IETF), its areas, and its working groups. Note that
15	   other groups may also distribute working documents as Internet-
16	   Drafts. Internet-Drafts are draft documents valid for a maximum of
17	   six months and may be updated, replaced, or obsoleted by other
18	   documents at any time. It is inappropriate to use Internet- Drafts
19	   as reference material or to cite them other than as "work in
20	   progress."

22	   The list of current Internet-Drafts can be accessed at
23	   http://www.ietf.org/ietf/1id-abstracts.txt.

25	   The list of Internet-Draft Shadow Directories can be accessed at
26	   http://www.ietf.org/shadow.html.

28	1. Abstract

30	   Mostly Pointless Lamp Switching (MPLampS) is an architecture for
31	   carrying electricity over IP (with an MPLS control plane). According
32	   to our marketing department, MPLampS has the potential to
33	   dramatically lower the price, ease the distribution and usage, and
34	   improve the manageability of delivering electricity. This document is
35	   motivated by such work as SONET/SDH over IP/MPLS [2] (with apologies
36	   to the authors). Readers of the previous work have been observed
37	   scratching their heads and muttering, "What next?". This document
38	   answers that question.

40	   This document has also been written as a public service. The "Sub-IP"
41	   area has been formed to give equal opportunity to those working on
42	   technologies outside of traditional IP networking to write
43	   complicated IETF drafts. There are possibly many who are wondering
44	   how to exploit this opportunity and attain high visibility. Towards
45	   this goal, we see the topics of "foo-over-MPLS" (or MPLS control for
46	   random technologies) as highly amenable for producing countless
47	   number of unimplementable drafts. This document illustrates the
48	   key ingredients that go into producing any "foo-over-MPLS" draft
49	   and may be used as a template for all such work.

51	Rajagopalan               Expires on 8/25/02                         1
52	2. Conventions used in this document

54	   The key words "MUST", "MUST NOT", "DO", "DON'T", "REQUIRED",
55	   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY",
56	   "MAY BE" and "OPTIONAL" in this document do not mean anything.

58	3. Pre-requisite for reading this document

60	   <Template note: This section on pre-requisite MUST be present in any
61	   foo-over-MPLS document>

63	   While reading this document, at various points the readers may have the
64	   urge to ask questions like, "does this make sense?", "is this
65	   feasible?," and "is the author sane?". The readers must have the
66	   ability to suppress such questions and read on. Other than this, no
67	   specific technical background is required to read this document. In
68	   certain cases (present document included), it may be REQUIRED that
69	   readers have no specific technical background.

71	4. Introduction

73	   <Template note: In this section, a rationale for "foo-over-MPLS" is
74	   cooked up>

76	   It was recently brought to our attention that the distribution
77	   network for electricity is not an IP network! After absorbing the
78	   shock that was delivered by this news, the following thoughts
79	   occurred to us:

81	   1.  Electricity distribution must be based on some outdated
82	       technology (called "Legacy Distribution System" or LDS in the
83	       rest of the document).
84	   2.  An LDS not based on the Internet technology means that two
85	       different networks (electricity and IP)_must be administered and
86	       managed. This leads to inefficiencies, higher cost and
87	       bureaucratic foul-ups (which possibly lead to blackouts in
88	       California. We are in the process of verifying this using
89	       simulations as part of a student's MS thesis).
90	   3.  The above means that a single network technology (i.e., IP) must
91	       be used to carry both electricity and Internet traffic.
92	   4.  An internet draft must be written to start work in this area,
93	       before someone else does.
94	   5.  Such a draft can be used to generate further drafts, ensuring
95	       that we (and CCAMP, MPLS or another responsible working group)
96	       will be busy for another year.
97	   6.  The draft can also be posted in the "white papers" section of
98	       our company web page, proclaiming us as revolutionary pioneers.

100	   Hence the present document.

102	Rajagopalan               Expires on 8/25/02                         2
103	5. Terminology

105	   <Template note: Any respectable "foo-over-MPLS" draft SHOULD have a
106	   terminology section>

108	   MPLampS: Mostly Pointless Lamp Switching - the architecture
109	   introduced in this document.

111	   Lamp: An end-system in the MPLampS architecture (clashes with the
112	   IETF notion of end-system but of course, we DON'T care).

114	   LER: Low-voltage Electricity Receptor - fancy name for "Lamp".

116	   ES: Electricity source - a generator.

118	   LSR: Load-Switching Router - an MPLampS device used in the core
119	   electricity distribution network.

121	   LDS: Legacy Distribution System - an inferior electricity
122	   distribution technology that MPLampS intends to replace.

124	   RSVP: Rather Screwed-up, but router Vendors Push it - an IP
125	   signaling protocol.

127	   RSVP-TE: RSVP with Tariff Extensions - RSVP adaptation for MPLampS,
128	   to be used in the new deregulated utilities environment.

130	   CRLDP: for CRying out Loud, Don't do rsvP - another IP signaling
131	   protocol.

133	   OSPF: Often Seizes-up in multiPle area conFigurations - a
134	   hierarchical IP routing protocol.

136	   ISIS: It's not oSpf, yet It somehow Survives - another routing
137	   protocol.

139	   OSPF-TE, ISIS-TE: OSPF and ISIS with Tariff Extensions.

141	   COPS: Policemen. Folks who scour all places for possibilities to
142	   slip in the Common Open Policy Service protocol.

144	   VPN: Voltage Protected Network - allows a customer with multiple
145	   sites to receive electricity with negligible voltage fluctuation due
146	   to interference from other customers.

148	   SUB-IP: SUBstitute IP everywhere - an effort in the IETF to get
149	   involved in technical areas outside of traditional IP networking
150	   (such as MPLampS).

152	   ITU: International Tariffed Utilities association - a utilities
153	   trade group whose work is often ignored by the IETF.

155	Rajagopalan               Expires on 8/25/02                         3
156	6. Background

158	   <Template note: This section must give a damning account of the
159	   current state of foo and then conclude by noting that foo-over-MPLS
160	   is the solution>

162	   We dug into the electricity distribution technology area to get some
163	   background. What we found stunned us, say, with the potency of a
164	   bare 230V A/C lead dropped into our bathtub while we were still in
165	   it. To put it simply, electricity is generated and distributed along
166	   a vast LDS which does not have a single router in it (LSR or
167	   otherwise)! Furthermore, the control of devices in this network is
168	   mostly manual, done by folks driving around in trucks. After
169	   wondering momentarily about how such a network can exist in the 21st
170	   century, we took a pencil and paper and sketched out a scenario for
171	   integrating the LDS network with the proven Internet technology. The
172	   fundamental points we came up with are:

174	   1. IP packets carry electricity in discrete, digitized form.
175	   2. Each packet would deliver electricity to its destination (e.g., a
176	      device with an IP address) on-demand.
177	   3. MPLS control will be used to switch packets within the core LDS,
178	      and in the edge premises. The architecture for this is referred
179	      to as Mostly-Pointless Lamp Switching (MPLampS).
180	   4. The MPLampS architectural model will accommodate both the overlay
181	      model, where the electricity consuming devices (referred to as
182	      "lamps") are operated over a distinct control plane, and the peer
183	      model, in which the lamps and the distribution network use a
184	      single control plane.
185	   5. RSVP-TE (RSVP with Tariff Extensions) will be used for
186	      establishing paths for electricity flow in a de-regulated
187	      environment.
188	   6. COPS will be used to support accounting and policy.

190	   After jotting these points down, we felt better. We then noted down
191	   the following immediate advantages of the proposed scheme:

193	   1. Switches and transformers in the LDS can be replaced by LSRs,
194	      thereby opening up a new market for routers.
195	   2. Electricity can be routed over the Internet to reach remote
196	      places which presently do not have electricity connections but
197	      have only Internet kiosks (e.g., rural India).
198	   3. Electrical technicians can be replaced by highly paid IP network
199	      administrators, and
200	   4. The IETF can get involved in another unrelated technology area.

202	   In the following, we describe the technical issues in a vague
203	   manner.

205	Rajagopalan               Expires on 8/25/02                         4
206	7. Electricity Encoding

208	   <Template note: This and the next two sections are difficult ones,
209	   since they get into the technical details. Readers MUST satisfy the
210	   pre-requisites mentioned in Section 3 to be able to read the document
211	   further>

213	   The Discrete Voltage Encoding (DVE) scheme has been specified in ITU
214	   standard G.110/230V [3] to digitize electrical voltages. In essence,
215	   an Electricity Source (ES) such as a generator is connected to a DV
216	   encoder that encodes the voltage and current produces a bit stream.
217	   This bit stream can be carried in IP packets to various destinations
218	   (referred to as LERs - Low-voltage Electricity Receptors) on-demand.
219	   At the destination, a DV decoder produces the right voltage and
220	   current based on the received bit stream. It is to be determined
221	   whether the Real-time Transport Protocol (RTP) can be used for
222	   achieving synchronization and end-to-end control. We leave draft
223	   writing opportunities in the RTP area to our friends and colleagues.

225	8. MPLampS Architecture

227	8.1  Overview

229	   In an LDS, the long-haul transmission of electricity is at high
230	   voltages. The voltage is stepped down progressively as electricity
231	   flows into local distribution networks and it is finally delivered
232	   to LERs at a standard voltage (e.g., 110V). Thus, the LDS is a
233	   hierarchical network. This immediately opens up the possibility of
234	   OSPF and ISIS extensions for routing electricity in a transmission
235	   network, but we'll contain the urge to delve into these productive
236	   internet draft areas until later. For the present, we limit our
237	   discussion merely to controlling the flow of electricity in an IP-
238	   based distribution network using MPLampS.

240	   Under MPLampS, a voltage is equated to a label. In the distribution
241	   network, each switching element and transformer is viewed as a load-
242	   switching router (LSR). Each IP packet carrying an electricity flow
243	   is assigned a label corresponding to the voltage. Electricity
244	   distribution can then be trivially reduced to the task of label
245	   (voltage) switching as electricity flows through the distribution
246	   network. The configuration of switching elements in the distribution
247	   network is done through RSVP-TE to provide electricity on demand.

249	   We admit that the above description is vague and sounds crazy. The
250	   example below tries to add more (useless) details, without removing
251	   any doubts the reader might have about the feasibility of this
252	   proposal:

254	   Example: Turning on a Lamp

256	   It is assumed that the lamp is controlled by an intelligent device
257	   (e.g, a (light) switch with an MPLampS control plane). Turning the
258	   lamp on causes the switch to issue an RSVP-TE request (a PATH

260	Rajagopalan               Expires on 8/25/02                         5
261	   message with new objects) for the electric flow. This PATH message
262	   traverses across the network to the ES. The RESV message issued in
263	   return sets up the label mappings in LSRs. Finally, electricity
264	   starts flowing along the path established. It is expected that the
265	   entire process will be completed within a few seconds, thereby
266	   giving the MPLampS architecture a distinct advantage over lighting a
267	   candle with a damp match stick.

269	8.2  Overlay vs Peer Models

271	   As noted before, there are two control plane models to be
272	   considered. Under the overlay model, the lamps and the distribution
273	   network utilize distinct control planes. Under the peer model, a
274	   single control plane is used. A number of arguments can be made for
275	   one model versus the other, and these will be covered in the
276	   upcoming framework draft. We merely observe here that it is the lamp
277	   vendors who prefer the peer model against the better judgement of
278	   the LSR vendors. We, however, want to please both camps regardless
279	   of the usefulness of either model. We therefore note here that
280	   MPLampS supports both models and also migration scenarios from
281	   overlay to peer.

283	8.3 Routing in the Core Network

285	   The above description of the hierarchical distribution system
286	   immediately opens up the possibility of applying OSPF and ISIS with
287	   suitable extensions. The readers may rest assured that we are
288	   already working on such concepts as voltage bundling, multi-area
289	   tariff extensions, insulated LSAs, etc. Future drafts will describe
290	   the details.

292	8.4 Voltage Protected Networks (VPNs)

294	   VPNs allow a customer with multiple sites to get guaranteed
295	   electricity supply with negligible voltage fluctuations due to
296	   interference from other customers. Indeed, some may argue that the
297	   entire MPLampS architecture may be trashed if not for the
298	   possibility of doing VPNs. Whatever be the case, VPNs are a hot
299	   topic today and the readers are forewarned that we have every
300	   intention of writing several drafts on this. Specifically, BGP-
301	   support for VPNs is an area we're presently eyeing with interest.

303	9.  Multicast

305	   <Template Note: Multicast is an obvious area for generating numerous
306	   impractical drafts. Every foo-over-MPLS draft SHOULD lay the
307	   groundwork for future drafts on multicast>

309	   It has been observed that there is a strong spatial and temporal
310	   locality in electricity demand. ITU Study Group 55 has studied this
311	   phenomenon for over a decade and has issued a preliminary report.
312	   This report states that when a lamp is turned on in one house, it is

314	Rajagopalan               Expires on 8/25/02                         6
315	   usually the case that lamps are turned on in neighboring houses at
316	   around the same time (usually at dusk) [4]. This observation has a
317	   serious implication on the scalability of the signaling mechanism.
318	   Specifically, the distribution network must be able to handle tens
319	   of thousands of requests all at once. The signaling load can be
320	   reduced if multicast delivery is used. Briefly, a request for
321	   electricity is not sent from the lamp all the way to an ES, but is
322	   handled by the first LSR that is already in the path to another
323	   lamp.

325	   Support for this requires the application of multicast routing
326	   protocols together with RSVP-TE shared reservation styles and the
327	   development of MPLampS multicast forwarding mode. We are currently
328	   studying the following multicast routing protocol:

330	   o DVMRP: Discrete Voltage Multicast Routing Protocol - this protocol
331	   works over existing voltage routing protocols but the danger here is
332	   that electricity is delivered to all lamps when any one lamp is
333	   turned on. Indeed, the switching semantics gets annoying - all lamps
334	   get turned on periodically and those not needed must be switched off
335	   each time manually.

337	   Other protocols we will eventually consider are Current-Based Tree
338	   (CBT) and Practically Irrelevant Multicast (PIM). An issue we are
339	   greatly interested in is multicast scope: we would like support for
340	   distributing electricity with varying scope, from lamps within a
341	   single Christmas tree to those in entire cities. Needless to say, we
342	   will write many detailed drafts on these topics as time progresses.

344	10. Security Considerations

346	   <Template Note: The following statement MUST be present in all foo-
347	   over-MPLS drafts>

349	   This document MUST be secured in a locked cabinet to prevent it from
350	   being disposed off with the trash.

352	11. Summary

354	   <Template Note: Acknowledge the lack of details in the current document
355	   and conclude with the dire warning that future drafts will provide
356	   more details>

358	   This document described the motivation and high level concepts behind
359	   Mostly Pointless Lamp Switching (MPLampS), an architecture for
360	   electricity distribution over IP. MPLampS utilizes DVE (discrete
361	   voltage encoding), and an MPLS control plane in the distribution
362	   network. Since the aim of this document is to be a high-visibility
363	   place-holder, we did not get into many details of MPLampS. Numerous
364	   future drafts, unfortunately, will attempt to provide these details.

366	Rajagopalan               Expires on 8/25/02                         7
367	12. References

369	   1.  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
370	       9, RFC 2026, October 1996.

372	   2.  "SONET/SDH Circuit Emulation Service Over MPLS (CEM)
373	       Encapsulation," Work in Progress.

375	   3.  International Tarriffed Utilities association draft standard,
376	       ITU G.110/230V, "Discrete Voltage Encoding", March, 1999.

378	   4.  International Tarriffed Utilities association technical report,
379	       ITU (SG-55) TR-432-2000, "Empirical Models for Energy
380	       Utilization", September, 2000.

382	13. Disclaimer

384	   The opinions expressed in this document are solely the author's.
385	   Company's opinions, as always, are proprietary and confidential and
386	   may be obtained under appropriate NDAs.

388	14. Author's Address

390	   Bala Rajagopalan
391	   Tellium, Inc.
392	   2 Crescent Place
393	   Ocean Port, NJ 07757
394	   Phone: 732-923-4237
395	   Email: braja@tellium.com

397	Rajagopalan               Expires on 8/25/02                         8