Subject: draft-ietf-rtgwg-cl-requirement-06-preview1 - part 1 - changes

From: Curtis Villamizar <[email-masked]>
Date: Sat, 02 Jun 2012 23:26:20 -0400

Hi RTGWG,

Thanks to Iftekhar for detailed comments on CL Requirements.  Thanks
also to comments from Iftekhar on CL Framework and followup from
Iftekhar and Kireeti that identified a new requirement.

This is in three parts to keep within the 40K file size limit.  Please
respond to this email and use the others are reference files.

This email is part 1.  I've includes partial diffs of XML source below
with some annotations.

In the next email (part 2) I'll send the full diffs of the XML source.

In the final email (part 3) I'll send the text file
draft-ietf-rtgwg-cl-requirement-06-preview1.txt

Please review the diffs.  I will submit a new version of
draft-ietf-rtgwg-cl-requirement aka Composite Link Requirements
shortly if there are no comments or if comments are resolved quickly.

Curtis

Annotations to the diffs start with "===>".  Note that XML comments
have no impact on the generated text document and were used in the
past as a way to pass notes amoung co-authors to look at changes.

Index: draft-ietf-rtgwg-cl-requirement.xml
===================================================================
RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-ietf-rtgwg-cl-requirement.xml,v
retrieving revision 1.2
diff -u -w -r1.2 draft-ietf-rtgwg-cl-requirement.xml
--- draft-ietf-rtgwg-cl-requirement.xml	30 Jan 2012 23:50:59 -0000	1.2
+++ draft-ietf-rtgwg-cl-requirement.xml	2 Jun 2012 22:37:04 -0000

==> added some ENTITY definitions for use in the references.

[...]

@@ -47,14 +54,112 @@
 <?rfc comments="yes"?>
 <?rfc inline="yes" ?>
 
-<!-- we have lost some comments and some changes based on email message:

==> I reviewed the old email messages that were referred to in the
    comment in the XML file.  Most of the comments in those old emails
    were quite stale.  A few still made sense.

+<!--
+
+  Recent changes in response to email.
+
+  These email messages were very old but there was a comment in the
+  XML source that we may have missed chages from them.  Two changes
+  result from these.
+
      Message-ID:
      [email-masked]
+
+     > FR: The precision of latency reporting should be at least 10% of
+     > the one way latency for latency of 1 ms or more.
+
+     Can we just state that it be configurable and that the default be
+     ... [as stated].
+
+     [...]
+
+     If you are considering keeping the text as is, then change "overload"
+     to something more meaningful, like maybe "congestion and queueing
+     delay" and make the last sentence a sentence (grammar doesn't parse).
+
+     Message-ID:
      [email-masked]
+
+     This email was a followup to the prior email.  Most of the places
+     where changes were suggested could not be found in the current text.

==> The new block of comments below just embeds some XML comment
    tracking why changes were made from the -05 to the -06 version.

+  These are more recent emails.
+
+     05/06 Curtis Villamizar  Re: Ref: Composite link drafts update and reques
+     Message-Id: <[email-masked]>
+
+     This was the last in a thread started by Iftekhar Hussain.  These
+     were six action items identified.
+
+  #1  Some rewording is needed in Section 3 to clarify MPLS based
+      component vs physical link component, the latter inclucing the
+      link layer.
+
+  #2  Add a cross reference to CL framework in Section 4.1.
+
+  #3  Add cross reference to CL framework near FR#8 and FR#9 regarding
+      delay metric granularity and inclusion of queuing delay and the
+      potential impacts on performance, oscillations, and stability.
+
+  #4  Add a cross reference to CL Use Cases in Section 4.3 to point
+      toward the brief description and references that support the
+      statement "Many techniques have been developed to balance the
+      distribution of flows across component links that connect the
+      same pair of nodes" and "...via composite links, other
+      techniques have been developed."
+
+  #5  Briefly explain the "delay discontinuity" that occurs when load
+      balancing puts traffic on a new path and clarify what is meant
+      by "minimally disruptive".
+
+  #6  It may help in some cases to clarify that something must be
+      implemented but must, should, or may be configurable and
+      therefore may be optionally deployed.  Doing so may require a
+      small change to many requirements as in most cases we have only
+      indicated where something must be implemented.
+
+     05/24 Curtis Villamizar  change to requirements (was Re: draft-so-yong-rt
+     Message-Id: <[email-masked]>
+
+     05/24 Kireeti Kompella   Re: change to requirements (was Re: draft-so-yon
+     Message-ID: <[email-masked]>
+
+     05/24 Kireeti Kompella   Re: change to requirements (was Re: draft-so-yon
+     Message-ID: <[email-masked]>
+
+     05/24 Curtis Villamizar  Re: change to requirements (was Re: draft-so-yon
+     Message-Id: <[email-masked]>
+
+     05/24 Kireeti Kompella   Re: change to requirements (was Re: draft-so-yon
+     Message-ID: <[email-masked]>
+
+     05/24 Curtis Villamizar  Re: change to requirements (was Re: draft-so-yon
+     Message-Id: <[email-masked]>
+
+     05/24 Iftekhar Hussain   RE: change to requirements (was Re: draft-so-yon
+     Message-ID: <[email-masked]>
+
+     06/01 Curtis Villamizar  Re: change to requirements (was Re: draft-so-yon
+     Message-Id: <[email-masked]>
+
+     The suggested text from these was:
+
+  [FR#N]   Load balancing MAY be used during sustained low traffic
+           periods to reduce the number of active component links for
+           the purpose of power reduction.
+
+  As with any load balancing change, a change initiated for the
+  purpose of power reduction may be minimally disruptive.  Typically
+  the disruption is limited to a change in delay characteristics and
+  the potential for a very brief period with traffic reordering.  The
+  network operator when configuring a network for power reduction
+  should weight the benefit of power reduction against the
+  disadvantage of a minimal disruption.
+
   -->
 
 <rfc category="info" ipr="trust200902"
-     docName="draft-ietf-rtgwg-cl-requirement-05">
+     docName="draft-ietf-rtgwg-cl-requirement-06-preview1">
 
   <front>
     <title abbrev="Composite Link Requirements">
@@ -123,39 +228,6 @@
       </address>
     </author>
 
==> Removed commented out prior authors.  Note that only five are
    allowed.  Frederic and Yuji contributed to early versions of this
    document and are thanked in the acknowledgement section.

-
-
-<!--
-    <author
-	    fullname="Frederic Jounay" initials="F." surname="Jounay">
-      <organization>France Telecom</organization>
-      <address>
-        <postal>
-          <street>2, avenue Pierre-Marzin</street>
-	  <code>22307</code>
-          <city>Lannion Cedex</city>
-	  <country>France</country>
-        </postal>
-        <email>[email-masked]</email>
-      </address>
-    </author>
-
-    <author
-	    fullname="Yuji Kamite" initials="Y." surname="Kamite">
-      <organization>NTT Communications Corporation</organization>
-      <address>
-        <postal>
-          <street>Granpark Tower</street>
-          <street>3-4-1 Shibaura, Minato-ku</street>
-          <city>Tokyo</city>
-	  <code>108-8118</code>
-	  <country>Japan</country>
-        </postal>
-        <email>[email-masked]</email>
-      </address>
-    </author>
- -->
-
     <date day="30" month="January" year="2012" />
 
     <!-- Meta-data Declarations -->

==> The change below is due to removing Appendix A and Appendix B and
    moving them to the CL Use Cases draft.  This is as agreed to in
    the Quebec IETF.  The citations (xref) changed from the appendices
    to the external document.

@@ -207,14 +279,9 @@
 	functional requirements that are as independent as possible of
 	protocol specifications (<xref target="FR" />). For certain
 	functional requirements this document describes a set of
-	derived protocol requirements (<xref target="DR" />).  Three
-	appendices provide supporting details as a summary of
-	existing/prior operator approaches (<xref
-	target="network-operator-practices" />), a summary of
-	implementation techniques and relevant protocol standards
-	(<xref target="multipath-bcp" />), and a summary of G.800
-	terminology used to define a composite link (<xref
-	target="G.800-Definitions" />).
+	derived protocol requirements (<xref target="DR" />).  <xref
+	target="G.800-Definitions" /> provides a summary of G.800
+	terminology used to define a composite link.
       </t>
 
       <section title="Requirements Language">

==> The change below addressed an outstanding comment from Tony Li
    asking for additional references.  We cite MPLS Encaps, RSVP-TE
    base document, LDP, MPLS-TP Framework, and PW Framework.  The
    abbreviations pt-pt, pt-mpt, and mpt-mpt appear no where else, so
    they are expanded.

@@ -236,12 +303,14 @@
 	target="RFC4762">RFC 4762</xref>) and VPMS <xref
 	target="I-D.ietf-l2vpn-vpms-frmwk-requirements">VPMS
 	Framework</xref>), Internet traffic encapsulated by at least
-	one MPLS label, and dynamically signaled MPLS or MPLS-TP LSPs
-	and pseudowires. The MPLS LSPs supporting these services may
-	be pt-pt, pt-mpt, or mpt-mpt.
+	one MPLS label (<xref target="RFC3032">RFC 3032</xref>), and
+	dynamically signaled MPLS (<xref target="RFC3209">RFC
+	3209</xref> or <xref target="RFC5036">RFC 5036</xref>) or
+	MPLS-TP LSPs (<xref target="RFC5921">RFC 5921</xref>) and
+	pseudowires (<xref target="RFC3985">RFC 3985</xref>). The MPLS
+	LSPs supporting these services may be point-to-point,
+	point-to-multipoint, or multipoint-to-multipoint.
       </t>
-  <!--  Tony Li Comment: Need many references here. Lucy provided 
-  ones for services, do we need ones for signaled MPLS and MPLS-TP?-->
       <t>
 	The locations in a network where these requirements apply are a
 	Label Edge Router (LER) or a Label Switch Router (LSR) as

==> This is a comment that Dave added noting an objection to negative
    requirements.  I'm fairly sure that we discussed this explicitly
    among authors and decided to keep it.  Last chance to object
    before -06.

@@ -252,8 +321,6 @@
 	requires Diffserv transparency (see <xref target="RFC4031">RFC
 	4031 5.5.2</xref>), and in general network operators do not
 	rely on the DSCP of Internet packets.
-<!-- DM: I recall that a comment from the list proposing deletion of
-     "negative" requirements.  It is duplicated in Appendix A. -->
       </t>
     </section>
 
==> As indicated in the terse comment, this is item #1 from the list
    of action items that resulted from the mail from Iftekhar.  For
    brevity I'll call this "Iftekhar's list".  The request was to
    clarify physical link vs logical link.  The lines starting with
    "+" contain the full new text.  This is in the definition of
    "Component Link".

@@ -280,23 +347,25 @@
 		is allowed.
 		</t>
 	      <t hangText="Component Link:">
-		A point-to-point physical or logical link that
-		preserves ordering in the steady state.  A component
-		link may have transient out of order events, but such
-		events must not exceed the network's specific NPO.
-		Examples of a physical link are: Lambda, Ethernet PHY,
-		and OTN.  Examples of a logical link are: MPLS LSP,
-		Ethernet VLAN, and MPLS-TP LSP.
+		A point-to-point physical link (including one or more
+		link layer) or a logical link that preserves ordering
+		in the steady state.  A component link may have
+		transient out of order events, but such events must
+		not exceed the network's specific NPO.  Examples of a
+		physical link are: any set of link layers over a WDM
+		wavelength or any supportable combination of Ethernet
+		PHY, PPP, SONET or OTN over a physical link.  Examples
+		of a logical link are: MPLS LSP, Ethernet VLAN,
+		MPLS-TP LSP.  A set of link layers supported over
+		pseudowire is a logical link that appears to the
+		client to be a physical link.
+		<!-- This is action item #1 -->
 		</t>
 	    </list>
 	  </t>

==> I think at least among co-authors and to a lesser extent on list
    or at the meetings we beat the definition of flow to death.  The
    comment reflecting distant past discussion was removed.

 	  <t hangText="Flow:">
 	    A sequence of packets that must be transferred in order on
 	    one component link.
-<!-- should we add "in order to maintain packet order"? DM: Reordering
-     is either not allowed or allowed subject to a specified frequency
-     in the requirements and stating only the first case as a
-     definition woud be inconsistent.-->
 	  </t>
 	  <t hangText="Flow identification:">
 	    The label stack and other information that uniquely

==> The next two changes below change citations from an appendix moved
    to the CL Use Cases draft to a citation to the external document.

@@ -311,7 +380,7 @@
 	  <t hangText="Network Performance Objective (NPO):">
 	    Numerical values for performance measures, principally
 	    availability, latency, and delay variation. See <xref
-	    target="network-operator-practices" /> for more details.
+	    target="I-D.symmvo-rtgwg-cl-use-cases" /> for more details.
 	  </t>
 	</list>
       </t>
@@ -331,7 +400,7 @@
 	  service disrupting event and the convergence of the routing
 	  and/or signaling protocols MUST occur within a time frame
 	  specified by NPO values. 
-	  <xref target="network-operator-practices" /> provides
+	  <xref target="I-D.symmvo-rtgwg-cl-use-cases" /> provides
 	  references and a summary of service types requiring a range
 	  of restoration times.
 	  <list counter="fr" hangIndent="4" style="format FR#%d">

==> Removed two comments from Dave to other authors asking to look at
    his change.  These comments are from the distant past.

@@ -378,15 +447,19 @@
 	      MUST be means to control the frequency of changing the
 	      component link over which a flow is placed.
 	    </t>
-<!-- need to mention minimized reordering somewhere DM: OK Now?-->
 	    <t>
 	      Management and diagnostic protocols MUST be able to
 	      operate over composite links.
 	    </t>
-<!-- if you mean MPLS-TP OAM, then please say so DM: This came from
-     NTT, I think scope is broader.-->
 	  </list>
 	</t>

==> This is item #2 from "Iftekhar's list".  The request was to add a
    reference to CL Framework where detailed discussion of scalability
    and stability can be found.  That sort of discussion does not
    belong in CL Requirements, but this single paragraph may help.

+	<t>
+	  Existing scaling techniques used in MPLS networks apply to
+	  MPLS networks which support Composite Links.  Scalability
+	  and stability are covered in more detail in <xref
+	  target="I-D.so-yong-rtgwg-cl-framework" />.
+	  <!-- This is action item #2. -->
+	</t>
       </section>
       <section anchor="layering"
 	       title="Component Links Provided by Lower Layer

==> The requirement wording below didn't sit well with a few people
    for a lot of time but no one suggested new wording.  Looking at a
    distant past email, I think the change below better reflects the
    intent.  Last chance to object before -06.

@@ -413,7 +486,9 @@
 	      communicate latency to the higher layer client network.
 	    </t>
 	    <t>
-	      The precision of latency reporting SHOULD be at least 10%
+	      The precision of latency reporting SHOULD be
+	      configurable.  A reasonable default SHOULD be provided.
+	      Implementations SHOULD support precision of at least 10%
 	      of the one way latencies for latency of 1 ms or more.
 	    </t>
 	    <t>

==> The change below was item #3 from "Iftekhar's list".  The request
    was to add some information about what types of delays were
    considered, particularly queuing delay, and briefly give
    reasoning.  This is not in the requirements list, but rather
    appears as a discussion paragraph after the requirements list that
    includes latency and jitter requirements.

@@ -439,6 +514,18 @@
 	    </t>
 	  </list>
 	</t>
+	<t>
+	  The intent is to measure the predominant latency in
+	  uncongested service provider networks, where geographic
+	  delay dominates and is on the order of milliseconds or more.
+	  The argument for including queuing delay is that it reflects
+	  the delay experienced by applications.  The argument against
+	  including queuing delay is that it if used in routing
+	  decisions it can result in routing instability.  This
+	  tradeoff is discussed in detail in <xref
+	  target="I-D.so-yong-rtgwg-cl-framework" />.
+	</t>
+	<!-- This is action item #3. -->
       </section>
       <section anchor="multipath-diff"
 	       title="Parallel Component Links with Different Characteristics">

==> In the change below two big comment blocks are removed.  These are
    discusion between myself and Dave from long ago that is resolved.
    Added after this is a new sentence that points the reader to CL
    Use Cases for descriptions of "existing techniques" and supporting
    references.  This was item #4 on "Iftekhar's list".

@@ -452,15 +539,12 @@
 	  that connect the same pair of nodes.  When the path for a
 	  flow can be chosen from a set of candidate nodes connected
 	  via composite links, other techniques have been developed.
-<!-- The following sections break the requirements into three cases
-     determined by the connectivity of the component links: a) same
-     pair of nodes or sites, b) same pair of nodes only, c) component
-     links connecting multiple pairs of nodes in a pair of sites. -->
-<!-- The set of case a, b, c above doesn't make sense.  Case a seems
-     to be the superset of case b and c.  If that is the intent, then
-     the text needs to be clear about it.  DM: That was the idea, case
-     a applies to both b and c to reduce amount of text. Rewrote this
-     however.  -->
+	  Refer to the Appendices in <xref
+	  target="I-D.symmvo-rtgwg-cl-use-cases" /> for a
+	  description of existing techniques and a set of references.
+	  <!-- This is action item #4. -->
+	</t>
+	<t>
 	  <list counter="fr" hangIndent="4" style="format FR#%d">
             <t>
 	      The solution SHALL measure traffic on a labeled traffic

==> This is a deletion of discussion that was embedded in the
    requirements.  That discussion was to a paragraph below the list
    of requirements, hopefully making it more clear that this
    discussion is a clarification about what "minimally disruptive" is
    intended to mean and not part of the requirements.

@@ -473,21 +557,8 @@
 	      When a traffic flow is moved from one component link to
 	      another in the same composite link between a set of
 	      nodes (or sites), it MUST be done so in a minimally
-	      disruptive manner.  <vspace blankLines="1" /> When a
-	      flow is moved from a current link to a target link with
-	      different latency, reordering can occur if the target
-	      link latency is less than that of the current or
-	      clumping can occur if target link latency is greater
-	      than that of the current. Therefore, some flows (e.g.,
-	      timing distribution, PW circuit emulation) are quite
-	      sensitive to these effects, which may be specified in an
-	      NPO or are needed to meet a user experience objective
-	      (e.g. jitter buffer under/overrun).
-	    </t>
-<!-- There are a few erros in the above paragraph.  New delay greater
-     than old delay results in a gap.  New delay less than old delay
-     results in reorder.  It is not practical to put playback buffers
-     in the network core. DM: Good catch. OK Now?  -->
+	      disruptive manner.
+	    </t>
 	    <t>
 	      The solution SHALL provide a means to identify flows
 	      whose rearrangement frequency needs to be bounded by a

==> Two stale comments, both long ago resolved, are now removed.

@@ -500,7 +571,6 @@
 	      means to indicate the flow identification field(s) which
 	      can be used along the flow path which can be used to
 	      perform this function.
-<!-- does not parse - reword.  makes sense but grammar error. DM: OK Now?-->
 	    </t>
 	    <t>
 	      The solution SHALL provide a means to indicate that a
@@ -512,7 +582,6 @@
 	      traffic flow shall select a component link with a
 	      maximum acceptable latency value as specified by
 	      protocol.
-<!-- or a targer latency? DM: Same as Max acceptable from Ning?-->
 	    </t>
 	    <t>
 	      The solution SHALL provide a means to indicate that a

==> Below the discussion about what "minimally disruptive" means is
    added.  As described in the annotation above, this was moved from
    within the list of requirements and placed after the list.  The
    term "delay discontinuity" is used to explain the type of
    "minimally disruptive" that occurs with current techniques, for
    which there is no practical remedy.  This expanded discussion is
    item #5 on "Iftekhar's list".

@@ -558,6 +627,31 @@
 	    </t>
 	  </list>
 	</t>
+	<t>
+	  A minimally disruptive change implies that as little
+	  disruption as is practical occurs.  Such a change can be
+	  achieved with zero packet loss.  A delay discontinuity may
+	  occur, which is considered to be a minimally disruptive
+	  event for most services if this type of event is
+	  sufficiently rare.  A delay discontinuity is an example of a
+	  minimally disruptive behavior corresponding to current
+	  techniques.
+	</t>
+	<t>
+	  A delay discontinuity is an isolated event which may greatly
+	  exceed the normal delay variation (jitter).  A delay
+	  discontinuity has the following effect.  When a flow is
+	  moved from a current link to a target link with lower
+	  latency, reordering can occur.  When a flow is moved from a
+	  current link to a target link with a higher latency, a time
+	  gap can occur.  Some flows (e.g., timing distribution, PW
+	  circuit emulation) are quite sensitive to these effects.  A
+	  delay discontinuity can also cause a jitter buffer underrun
+	  or overrun affecting user experience in real time voice
+	  services (causing an audible click).  These sensitivities
+	  may be specified in an NPO.
+	</t>
+	<!-- This is action item #5. -->
       </section>
     </section>
 
==> The entertaining comment below accompanies some discussion within
    a requirement that was commented out long ago.  So far no one has
    missed that discussion.

@@ -571,13 +665,6 @@
 	    The solution SHOULD attempt to extend existing protocols
 	    wherever possible, developing a new protocol only if this
 	    adds a significant set of capabilities.
-<!-- This is not a requirement.  It is a religious manifesto -
-	    &lt;vspace blankLines="1" /&gt; The vast majority of network
-	    operators have provisioned L3VPN services over LDP. Many
-	    have deployed L2VPN services over LDP as well. TE
-	    extensions to IGP and RSVP-TE are viewed as being overly
-	    complex by some operators.
- -->
 	  </t>
 	  <t>
 	    A solution SHOULD extend LDP capabilities to meet

==> Erroneous capitalization down-cased.  After that a stale comment
    is removed.

@@ -601,7 +688,7 @@
 	    rely on extensions to the IGP.
 	  </t>
 	  <t>
-	    The Solution SHOULD support composite link IGP
+	    The solution SHOULD support composite link IGP
 	    advertisement that results in convergence time better than
 	    that of advertising the individual component links.  The
 	    solution SHALL be designed so that it represents the range
@@ -624,7 +711,6 @@
 	    duration of unavailability. The resignaling time of the
 	    solution MUST not increase significantly as compared with
 	    current methods.
-<!-- Same here.  Some rewording is needed. DM: Better now?-->
 	  </t>
 	</list>
       </t>

==> This is item #6 on "Iftekhar's list".  Somewhere we needed to say
    that the many statements that are worded in the form of "A
    solution MUST do the following" means that the implementation MUST
    support it, the implementation MUST make it optional and SHOULD in
    most cases disable it by default, and the provider MAY decide to
    enable it.  This is added to the Management Requirements section.

@@ -665,6 +751,17 @@
 	    Management Plane SHOULD provide the means for an operator
 	    to initiate an optimization process.
 	  </t>
+	  <t>
+	    Any statement which requires the solution to support some
+	    new functionality through use of the words new
+	    functionality, SHOULD be interpretted as follows.  The
+	    implementation either MUST or SHOULD support the new
+	    functionality depending on the use of either MUST or
+	    SHOULD in the requirements statement.  The implementation
+	    SHOULD in most or all cases allow any new functionality to
+	    be individually enabled or disabled through configuration.
+	  </t>
+	  <!-- This is item #6. -->
 	</list>
       </t>
 
==> This is an addition to the Acknowledgements section.

@@ -687,10 +784,15 @@
 	the RTGWG mailing list that are reflected in versions
 	following the IETF77 meeting.
       </t>
+      <t>
+	Iftekhar Hussain and Kireeti Kompella made comments on the
+	RTGWG mailing list after IETF82 that identified a new
+	requirement.  Iftekhar Hussain made numerous valuable comments
+	on the RTGWG mailing list that resulted in improvements to
+	document clarity.
+      </t>
     </section>
 
-    <!-- Possibly a 'Contributors' section ... -->
-
     <section anchor="IANA" title="IANA Considerations">
       <t>This memo includes no request to IANA.</t>
     </section>

==> Some references were added.  So references with no citations in
    the document body were removed.

@@ -727,20 +829,20 @@
 
     <references title="Informative References">
 
[...]

@@ -749,10 +851,16 @@
       
[...]

@@ -769,57 +877,6 @@

     </references>
 
-    <references title="Appendix References">
-    <!-- add diffserv framework -->

[...]

-    </references>

==> The last remnants of the two appendices that were moved to the Use
    Cases draft are now gone.

-    <section anchor="network-operator-practices"
-	     title="Existing Network Operator Practices and Protocol Usage">
-
-      <t>
-	The network operator practices appendix has been moved to a
-	separate document.  When that document has an XML I-D tag the
-	references to this appendix will be changed to that document
-	and this appendix will be deleted.
-      </t>
-
-    </section>
-
-    <section anchor="multipath-bcp"
-	     title="Existing Multipath Standards and Techniques">
-
-      <t>
-	The multipath standards and techniques appendix has been moved
-	to a separate document.  When that document has an XML I-D tag
-	the references to this appendix will be changed to that
-	document and this appendix will be deleted.
-      </t>
-
-    </section>
-
     <section anchor="G.800-Definitions"
 	     title="ITU-T G.800 Composite Link Definitions and Terminology">
       <t>

==> A few more stale comments in the XML were removed.

@@ -860,22 +917,17 @@
 	    A set of one or more nodes (i.e., LER or LSR) and links.
 	    As a special case it can represent a site comprised of
 	    multiple nodes.
-<!-- this should be listed as a special case of a subnet DM: OK? -->
 	  </t>
 	  <t hangText="Forwarding Relationship:">
 	    Configured forwarding between ports on a subnetwork. It
 	    may be connectionless (e.g., IP, not considered in this
 	    draft), or connection oriented (e.g., MPLS signaled or
 	    configured).
-<!-- conflict with prior statement that limits scope to MPLS with a CP
-     DM: OK now?-->
 	  </t>
 	  <t hangText="Component Link:">
 	    A topolological relationship between subnetworks (i.e., a
 	    connection between nodes), which may be a wavelength,
 	    circuit, virtual circuit or an MPLS LSP.
-<!-- do we really mean subnetwork here or site?  DM: Site is special
-     case of subnet.  If subnet, ECMP? DM: Question unclear. -->
 	  </t>
 	</list>
       </t>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 03 Jun 2012 11:28:26 -0400

In message <[email-masked]>
 
> Iftekhar and Kireeti that identified a new requirement.

And Lucy Yong was in on this discussion.

> [ ... annotated diffs deleted ... ]

Oops - missed something.

We should acknowledge John Scudder, Alex Zinin, Papadimitriou Dimitri,
Lou Berger, Alia Atlas, John Drake, and Eric Osborne for valuable
comments.

In the interest of full disclosure of affiliation ---

Ning So's affiliation needs to change.  IMHO Verizon should be
acknowledged for support of Ning's work while at Verizon.

Infinera would like to be acknowledged for their support of my work
while at Infinera and continued support.

Small diffs for these later.

Curtis