RE: CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework)

[Iftekhar Hussain <[e-mail]>]

Curtis,

Sorry for the delayed response. I was off work for few days. Please see  in line.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, June 20, 2012 9:40 AM
To: Iftekhar Hussain
Cc: [e-mail]; RTGWG
Subject: CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework)


Iftekhar,

In a prior message my reply included:

   Actually it is not difficult in principle to provide cross
   references but it is somewhat time consuming.  It also turns out
   that it isn't very useful.  The reason is that documents covering
   many topics must consider certain groups of requirements such as
   backward compatibility and general network management.  I did the
   exercise briefly, but didn't expand the text yet.  I'll post diffs
   if it seems to add more clarity than bloat.

Below are diffs that add cross references to the named groups of requirements in "Brief Review of Requirements" (Section 7.1).  For each document or document topic called for in "Required Document Coverage" (Section 7.2) there are cross references to those groups of requirements.


Another change is dropping the subsection "Component Group Metric" and adding the text (one paragraph) to the prior subsection "Component Link Grouping".  Please comment on this change as well.

The first diff chunk just adds comments that number the requirement groups.  The remaining long diff chunk includes most of "Required Document Coverage" (Section 7.2) where the diffs are mostly addition of comments giving just the requirement groups cited and then a brief paragraph making the citation, referring directly to the requirement group names.  

The diffs at the very end drop the cross references to the "Component Group Metric" subsection (anchor=r.metric) which always accompany a cross reference to the "Component Link Grouping" subsection (r.bundle), the subsection that this paragraph was combined into.



Again, if you thik this adds more clarity rather than added bloat, then I will keep the diffs.  Otherwise, I will back out the diffs.
Now that I've done this I can see where this could be a useful reminder to authors and reviewers of specific later documents, somewhat like a checklist that needs to be considered to see if the document completely addresses the requirements relevant to the topic.
If this is considered very useful, then I'll change the requirement groups from a list with named entries into subsections so that I can use the XML anchor and xref to automate the cross references.

[Iftekhar] I believe it adds clarity. Also adding a checklist sounds like a good idea.

Thanks,
Iftekhar

Curtis


cvs diff: Diffing .
Index: draft-so-yong-rtgwg-cl-framework.xml
===================================================================
RCS file: /home/cvs/CVS-occnc/customers/ietf/rtg-cl/draft-so-yong-rtgwg-cl-framework.xml,v
retrieving revision 1.15
diff -w -U20 -r1.15 draft-so-yong-rtgwg-cl-framework.xml
--- draft-so-yong-rtgwg-cl-framework.xml	15 Jun 2012 19:34:10 -0000	1.15
+++ draft-so-yong-rtgwg-cl-framework.xml	20 Jun 2012 16:11:58 -0000
@@ -1875,91 +1875,100 @@
       <t>
 	This section first summarizes and groups requirements.  A set
 	of documents coverage groupings are proposed with existing
 	works-in-progress noted where applicable.  The set of
 	extensions are then grouped by protocol affected as a
 	convenience to implementors.
       </t>
 
       <section anchor="sect.reqm-review"
 	       title="Brief Review of Requirements">
 
 	<t>
 	  The following list provides a categorization of requirements
 	  specified in <xref target="I-D.ietf-rtgwg-cl-requirement"
 	  /> along with a short phrase indication what topic the
 	  requirement covers.
 	</t>
 
 	<t>
 	  <list hangIndent="4" style="hanging">
+	    <!-- #1 -->
 	    <t hangText="routing information aggregation">
 	      <vspace blankLines="0" />
 	      FR#1 (routing summarization), FR#20 (composite link may
 	      be a component of another composite link)
 	    </t>
+	    <!-- #2 -->
 	    <t hangText="restoration speed">
 	      <vspace blankLines="0" />
 	      FR#2 (restoration speed meeting NPO), FR#12 (minimally
 	      disruptive load rebalance), DR#6 (fast convergence),
 	      DR#7 (fast worst case failure convergence)
 	    </t>
+	    <!-- #3 -->
 	    <t hangText="load distribution, stability, minimal disruption">
 	      <vspace blankLines="0" />
 	      FR#3 (automatic load distribution), FR#5 (must not
 	      oscillate), FR#11 (dynamic placement of flows), FR#12
 	      (minimally disruptive load rebalance), FR#13 (bounded
 	      rearrangement frequency), FR#18 (flow placement must
 	      satisfy NPO), FR#19 (flow identification finer than per
 	      top level LSP), MR#6 (operator initiated flow rebalance)
 	    </t>
+	    <!-- #4 -->
 	    <t hangText="backward compatibility and migration">
 	      <vspace blankLines="0" />
 	      FR#4 (smooth incremental deployment), FR#6 (management
 	      and diagnostics must continue to function), DR#1
 	      (extend existing protocols), DR#2 (extend LDP, no LDP
 	      TE)
 	    </t>
+	    <!-- #5 -->
 	    <t hangText="delay and delay variation">
 	      <vspace blankLines="0" />
 	      FR#7 (expose lower layer measured delay), FR#8
 	      (precision of latency reporting), FR#9 (limit latency on
 	      per LSP basis), FR#15 (minimum delay path), FR#16
 	      (bounded delay path), FR#17 (bounded jitter path)
 	    </t>
+	    <!-- #6 -->
 	    <t hangText="admission control, preemption, traffic engineering">
 	      <vspace blankLines="0" />
 	      FR#10 (admission control, preemption), FR#14 (packet
 	      ordering), FR#21 (ingress specification of path), FR#22
 	      (path symmetry), DR#3 (IP and LDP traffic), MR#3
 	      (management specification of path)
 	    </t>
+	    <!-- #7 -->
 	    <t hangText="single vs multiple domain">
 	      <vspace blankLines="0" />
 	      DR#4 (IGP extensions allowed within single domain), DR#5
 	      (IGP extensions disallowed in multiple domain case)
 	    </t>
+	    <!-- #8 -->
 	    <t hangText="general network management">
 	      <vspace blankLines="0" />
 	      MR#1 (polling, configuration, and notification), MR#2
 	      (activation and de-activation)
 	    </t>
+	    <!-- #9 -->
 	    <t hangText="path determination, connectivity verification">
 	      <vspace blankLines="0" />
 	      MR#4 (path trace), MR#5 (connectivity verification)
 	    </t>
 	  </list>
 	</t>
 
 	<t>
 	  The above list is not intended as a substitute for <xref
 	  target="I-D.ietf-rtgwg-cl-requirement" />, but rather as a
 	  concise grouping and reminder or requirements to serve as a
 	  means of more easily determining requirements coverage of a
 	  set of protocol documents.
 	</t>
 
       </section>
 
       <section anchor="sect.doclist"
 	       title="Required Document Coverage">
 
@@ -1990,412 +1999,674 @@
 	      <t>
 		An index is needed that if included in an ERO would
 		indicate the need to place the LSP on any one
 		component within the group.
 	      </t>
 	      <t>
 		A second index is needed that if included in an ERO
 		would indicate the need to balance flows within the
 		LSP across all components of the group.  This is
 		equivalent to the "all-ones" component for the entire
 		bundle.
 	      </t>
 	    </list>
 	    <xref target="I-D.ospf-cc-stlv" /> can be extended to
 	    include multipath treatment capabilities.  An ISIS
 	    solution is also needed.  An extension of RSVP-TE
 	    signaling is needed to indicate multipath treatment
 	    preferences.
 	  </t>
 
-	</section>
+	  <t>
+	    If a component group is allowed to support all of the
+	    parameters of a link bundle, then a group TE metric would
+	    be accommodated.  This can be supported with the component
+	    TLV (C-TLV) defined in <xref target="I-D.ospf-cc-stlv" />.
+	  </t>
 
-	<section anchor="r.metric"
-		 title="Component Group Metric">
+	  <!-- #1 (routing information aggregation),
+	       also:
+	         #2 (restoration speed),
+		 #4 (backward compatibility and migration),
+		 #8 (general network management)
+	  -->
 
 	  <t>
-	    If a group is allowed to support all of the parameters of
-	    a link bundle, then a group TE metric would be
-	    accommodated.  This can be supported with the component
-	    TLV (C-TLV) defined in <xref target="I-D.ospf-cc-stlv" />.
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "routing information aggregation" set of
+	    requirements.  The "restoration speed", "backward
+	    compatibility and migration", and "general network
+	    management" requirements must also be considered.
 	  </t>
 
 	</section>
 
 	<section anchor="r.delay"
 		 title="Delay and Jitter Extensions">
 
 	  <t>
 	    A extension is needed in the IGP-TE advertisement to
 	    support delay and delay variation for links, link bundles,
 	    and forwarding adjacencies.  Whatever mechanism is
 	    described must take precautions that insure that route
 	    oscillations cannot occur.  <xref
 	    target="I-D.wang-ccamp-latency-te-metric" /> may be a good
 	    starting point.
 	  </t>
 
+	  <!-- #5 (delay and delay variation),
+	       also
+	         #2 (restoration speed),
+		 #4 (backward compatibility and migration),
+		 #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "delay and delay variation" set of requirements.
+	    The "restoration speed", "backward compatibility and
+	    migration", and "general network management" requirements
+	    must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.path"
 		 title="Path Selection and Admission Control">
 
 	  <t>
 	    Path selection and admission control changes must be
 	    documented in each document that proposes a protocol
 	    extension that advertises a new capability or parameter
 	    that must be supported by changes in path selection and
 	    admission control.
 	  </t>
 
+	  <!-- #3 (load distribution, stability, minimal disruption),
+	       #6 (admission control, preemption, traffic engineering),
+	       also
+	         #2 (restoration speed),
+		 #9 (path determination, connectivity verification),
+		 also
+		   #4 (backward compatibility and migration),
+		   #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    are the "load distribution, stability, minimal disruption"
+	    and "admission control, preemption, traffic engineering"
+	    sets of requirements.  The "restoration speed" and "path
+	    determination, connectivity verification" requirements
+	    must also be considered.  The "backward compatibility and
+	    migration", and "general network management" requirements
+	    must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.adaptive"
 		 title="Dynamic Multipath Balance">
 
 	  <t>
 	    FR#11 explicitly calls for dynamic load balancing similar
 	    to existing adaptive multipath.  In implementations where
 	    flow identification uses a coarse granularity, the
 	    adjustments would have to be equally coarse, in the worst
 	    case moving entire LSP.  The impact of flow identification
 	    granularity and potential adaptive multipath approaches
 	    may need to be documented in greater detail than provided
 	    here.
 	  </t>
 
+	  <!-- #2 (restoration speed),
+	       #3 (load distribution, stability, minimal disruption),
+	       also
+	         #9 (path determination, connectivity verification),
+		 also
+		   #4 (backward compatibility and migration),
+		   #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    are the "restoration speed" and the "load distribution,
+	    stability, minimal disruption" sets of requirements.  The
+	    "path determination, connectivity verification"
+	    requirements must also be considered.  The "backward
+	    compatibility and migration", and "general network
+	    management" requirements must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.freq-balance"
 		 title="Frequency of Load Balance">
 
 	  <t>
 	    IGP-TE and RSVP-TE extensions are needed to support
 	    frequency of load balancing rearrangement called for in
 	    FR#13, and FR#15-FR#17.  Constraints are not defined in
 	    RSVP-TE, but could be modeled after administrative
 	    attribute affinities in RFC3209 and elsewhere.
 	  </t>
 
+	  <!-- #3 (load distribution, stability, minimal disruption),
+	       also
+	         #9 (path determination, connectivity verification),
+	         also
+	           #4 (backward compatibility and migration),
+		   #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "load distribution, stability, minimal disruption"
+	    set of requirements.  The "path determination,
+	    connectivity verification" must also be considered.  The
+	    "backward compatibility and migration" and "general
+	    network management" requirements must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.ll-ul-leak"
 		 title="Inter-Layer Communication">
 
 	  <t>
 	    Lower layer to upper layer communication called for in
 	    FR#7 and FR#20.  This is addressed for a subset of
 	    parameters related to packet ordering in <xref
 	    target="I-D.villamizar-mpls-tp-multipath" /> where layers
 	    are MPLS.  Remaining parameters, specifically delay and
 	    delay variation, need to be addressed.  Passing
 	    information from a lower non-MPLS layer to an MPLS layer
 	    needs to be addressed, though this may largely be generic
 	    advice encouraging a coupling of MPLS to lower layer
 	    management plane or control plane interfaces.  This topic
 	    can be addressed in each document proposing a protocol
 	    extension, where applicable.
 	  </t>
 
+	  <!-- #2 (restoration speed),
+	       also
+	         #4 (backward compatibility and migration),
+		 #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "restoration speed" set of requirements.  The
+	    "backward compatibility and migration" and "general
+	    network management" requirements must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.mp-tp"
 		 title="Packet Ordering Requirements">
 
 	  <t>
 	    A document is needed to define extensions supporting
 	    various packet ordering requirements, ranging from
 	    requirements to preservce microflow ordering only, to
 	    requirements to preservce full LSP ordering (as in
 	    MPLS-TP).  This is covered by <xref
 	    target="I-D.villamizar-mpls-tp-multipath" /> and <xref
 	    target="I-D.villamizar-mpls-tp-multipath-te-extn" />.
 	  </t>
 
+	  <!-- #6 (admission control, preemption, traffic engineering),
+	       #9 (path determination, connectivity verification),
+	       also
+	         #4 (backward compatibility and migration),
+		 #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    are the "admission control, preemption, traffic
+	    engineering" and the "path determination, connectivity
+	    verification" sets of requirements.  The "backward
+	    compatibility and migration" and "general network
+	    management" requirements must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.disrupt"
 		 title="Minimally Disruption Load Balance">
 
 	  <t>
 	    The behavior of hash methods used in classic multipath
 	    needs to be described in terms of FR#12 which calls for
 	    minimally disruptive load adjustments.  For example,
 	    reseeding the hash violates FR#12.  Using modulo
 	    operations is significantly disruptive if a link comes or
 	    goes down, as pointed out in <xref target="RFC2992" />.
 	    In addition, backwards compatibility with older hardware
 	    needs to be accommodated.
 	  </t>
 
+	  <!-- #3 (load distribution, stability, minimal disruption) -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "load distribution, stability, minimal disruption"
+	    set of requirements.
+	  </t>
+
 	</section>
 
 	<section anchor="r.symmetry"
 		 title="Path Symmetry">
 
 	  <t>
 	    Protocol extensions are needed to support dynamic load
 	    balance as called for to meet FR#22 (path symmetry) and to
 	    meet FR#11 (dynamic placement of flows).  Currently path
 	    symmetry can only be supported in link bundling if the
 	    path is pinned.  When a flow is moved both ingress and
 	    egress must make the move as close to simultaneously as
 	    possible to satisfy FR#22 and FR#12 (minimally disruptive
 	    load rebalance).  If a group of flows are identified using
 	    a hash, then the hash must be identical on the pair of LSR
 	    at the endpoint, using the same hash seed and with one
 	    side swapping source and destination.  If the label stack
 	    is used, then either the entire label stack must be a
 	    special case flow identification, since the set of labels
 	    in either direction are not correlated, or the two LSR
 	    must conspire to use the same flow identifier.  For
 	    example, using a common entropy label value, and using
 	    only the entropy label in the flow identification would
 	    satisfy this requirement.
 	  </t>
 
+	  <!-- #3 (load distribution, stability, minimal disruption),
+	       #6 (admission control, preemption, traffic engineering),
+	       also
+	         #4 (backward compatibility and migration),
+		 #8 (general network management),
+		 helps with
+		   #9 (path determination, connectivity verification)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    are the "load distribution, stability, minimal disruption"
+	    and the "admission control, preemption, traffic
+	    engineering" sets of requirements.  The "backward
+	    compatibility and migration" and "general network
+	    management" requirements must also be considered.  Path
+	    symetry simplifies support for the "path determination,
+	    connectivity verification" set of requirements, but with
+	    significant complexity added elsewhere.
+	  </t>
+
 	</section>
 
 	<section anchor="r.stability"
 		 title="Performance, Scalability, and Stability">
 
 	  <t>
 	    A separate document providing analysis of performance,
 	    scalability, and stability impacts of changes may be
 	    needed.  The topic of traffic adjustment oscillation must
 	    also be covered.  If sufficient coverage is provided in
 	    each document covering a protocol extension, a separate
 	    document would not be needed.
 	  </t>
 
+	  <!-- #2 (restoration speed), 
+	       impacts other documents,
+	       should be cited by:
+	         r.bundle, r.delay, r.path, r.symmetry, r.ip-ldp,
+		 r.ldp-extn, r.pw-extn, r.multi-domain
+	       possibly r.adaptive, r.freq-balance
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "restoration speed" set of requirements.  This is
+	    not a simple topic and not a topic that is well served by
+	    scattering it over multiple documents, therefore it may be
+	    best to put this in a separate document and put citations
+	    in documents called for in
+	    <xref target="r.bundle" />,
+	    <xref target="r.delay" />,
+	    <xref target="r.path" />,
+	    <xref target="r.symmetry" />,
+	    <xref target="r.ip-ldp" />,
+	    <xref target="r.ldp-extn" />,
+	    <xref target="r.pw-extn" />, and
+	    <xref target="r.multi-domain" />.
+	    Citation may also be helpful in
+	    <xref target="r.adaptive" />, and
+	    <xref target="r.freq-balance" />.
+	  </t>
+
 	</section>
 
 	<section anchor="r.ip-ldp"
 		 title="IP and LDP Traffic">
 
 	  <t>
 	    A document is needed to define the use of measurements
 	    native IP and native LDP traffic levels to reduce link
 	    advertised bandwidth amounts.
 	  </t>
 
+	  <!-- #3 (load distribution, stability, minimal disruption),
+	       #6 (admission control, preemption, traffic engineering),
+	       also
+	         #9 (path determination, connectivity verification),
+		 also
+		   #4 (backward compatibility and migration),
+		   #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    are the "load distribution, stability, minimal disruption"
+	    and the "admission control, preemption, traffic
+	    engineering" set of requirements.  The "path
+	    determination, connectivity verification" must also be
+	    considered.  The "backward compatibility and migration"
+	    and "general network management" requirements must also be
+	    considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.ldp-extn"
 		 title="LDP Extensions">
 
 	  <t>
 	    Extending LDP is called for in DR#2.  LDP can be extended
 	    to couple FEC admission control to local resource
 	    availability without providing LDP traffic engineering
 	    capability.  Other LDP extensions such as signaling a
 	    bound on microflow size and LDP LSP requirements would
 	    provide useful information without providing LDP traffic
 	    engineering capability.
 	  </t>
 
+	  <!-- #6 (admission control, preemption, traffic engineering),
+	       also
+	         #4 (backward compatibility and migration),
+		 #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "admission control, preemption, traffic
+	    engineering" set of requirements.  The "backward
+	    compatibility and migration" and "general network
+	    management" requirements must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.pw-extn"
 		 title="Pseudowire Extensions">
 
 	  <t>
 	    PW extensions such as signaling a bound on microflow size
 	    and PW requirements would provide useful information.
 	  </t>
 
+	  <!-- #6 (admission control, preemption, traffic engineering),
+	       also
+	         #4 (backward compatibility and migration),
+	         #8 (general network management)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    is the "admission control, preemption, traffic
+	    engineering" set of requirements.  The "backward
+	    compatibility and migration" and "general network
+	    management" requirements must also be considered.
+	  </t>
+
 	</section>
 
 	<section anchor="r.multi-domain"
 		 title="Multi-Domain Composite Link">
 
 	  <t>
 	    <!-- fix me -->
 	    DR#5 calls for Composite Link to span multiple network
 	    topologies.  Component LSP may already span multiple
 	    network topologies, though most often in practice these
 	    are LDP signaled.  Component LSP which are RSVP-TE
 	    signaled may also span multiple network topologies using
 	    at least three existing methods (per domain <xref
 	    target="RFC5152" />, BRPC <xref target="RFC5441" />, PCE
 	    <xref target="RFC4655" />).  When such component links are
 	    combined in a Composite Link, the Composite Link spans
 	    multiple network topologies.  It is not clear in which
 	    document this needs to be described or whether this
 	    description in the framework is sufficient.  The authors
 	    and/or the WG may need to discuss this.  DR#5 mandates
 	    that IGP-TE extension cannot be used.  This would disallow
 	    the use of <xref target="RFC5316" /> or <xref
 	    target="RFC5392" /> in conjunction with <xref
 	    target="RFC5151" />.
 	  </t>
 
+	  <!-- #7 (single vs multiple domain),
+	       #6 (admission control, preemption, traffic engineering),
+	       also
+	         #1 (routing information aggregation),
+		 #3 (load distribution, stability, minimal disruption),
+		 #5 (delay and delay variation),
+		 also
+		   #4 (backward compatibility and migration),
+		   #8 (general network management),
+		   #9 (path determination, connectivity verification)
+	  -->
+
+	  <t>
+	    The primary focus of this document, among the sets of
+	    requirements listed in <xref target="sect.reqm-review" />
+	    are "single vs multiple domain" and "admission control,
+	    preemption, traffic engineering".  The "routing
+	    information aggregation" and "load distribution,
+	    stability, minimal disruption" requirements need attention
+	    due to their use of the IGP in single domain Composite
+	    Link.  Other requirements such as "delay and delay
+	    variation", can more easily be accomodated by carrying
+	    metrics within BGP.  The "path determination, connectivity
+	    verification" requirements need attention due to
+	    requirements to restrict disclosure of topology
+	    information across domains in multi-domain deployments.
+	    The "backward compatibility and migration" and "general
+	    network management" requirements must also be considered.
+	  </t>
+
 	</section>
 
       </section>
 
       <section anchor="sect.open-issues"
 	       title="Open Issues Regarding Requirements">
 
 	<t>
 	  <!-- fix me -->
 	  Note to co-authors: This section needs to be reduced to an
 	  empty section and then removed.
 	</t>
 
 	<t>
 	  The following topics in the requirements document are not
 	  addressed.  Since they are explicitly mentioned in the
 	  requirements document some mention of how they are supported
 	  is needed, even if to say nother needed to be done.  If we
 	  conclude any particular topic is irrelevant, maybe the topic
 	  should be removed from the requirement document.  At that
 	  point we could add the management requirements that have
 	  come up and were missed.
 	  <list style="numbers">
 	    <t>
 	      L3VPN RFC 4364, RFC 4797,L2VPN RFC 4664, VPWS, VPLS RFC
 	      4761, RFC 4762 and VPMS VPMS Framework
 	      (draft-ietf-l2vpn-vpms-frmwk-requirements).  It is not
 	      clear what additional Composite Link requirements these
 	      references imply, if any.  If no additional requirements
 	      are implied, then these references are considered to be
 	      informational only.
+	      <!-- Dave added that, so Dave needs to answer this. -->
 	    </t>
 	    <t>
 	      Migration may not be adequately covered in <xref
 	      target="sect.compat" />.  It might also be necessary to
-	      say more here on performance, scalability, and
-	      stability.  Comments on this from co-authors or the WG?
+	      say more here on performance, scalability, and stability
+	      as it related to migration.  Comments on this from
+	      co-authors or the WG?
+	      <!-- This might be a topic for r.bundle, r.metric -->
 	    </t>
 	    <t>
 	      We may need a performance section in this document to
 	      specifically address #DR6 (fast convergence), and #DR7
 	      (fast worst case failure convergence), though we do
 	      already have scalability discussion.  The performance
 	      section would have to say "no worse than before, except
 	      were there was no alternative to make it very slightly
 	      worse" (in a bit more detail than that).  It would also
 	      have to better define the nature of the performance
 	      criteria.
+	      <!-- need r.stability ? - or embed in other docs? -->
 	    </t>
 	  </list>
 	</t>
 
       </section>
 
       <section anchor="sect.by-protocol"
 	       title="Framework Requirement Coverage by Protocol">
 
 	<t>
 	  As an aid to implementors, this section summarizes
 	  requirement coverage listed in <xref target="sect.doclist"
 	  /> by protocol or LSR functionality affected.
 	</t>
 
 	<t>
 	  Some documentation may be purely informational, proposing no
 	  changes and proposing usage at most.  This includes <xref
 	  target="r.path" />, <xref target="r.disrupt" />, <xref
 	  target="r.stability" />, and <xref target="r.multi-domain"
 	  />.
 	</t>
 
 	<t>
 	  <xref target="r.symmetry" /> may require a new protocol.
 	</t>
 
 	<section anchor="sect.by-igp"
 		 title="OSPF-TE and ISIS-TE Protocol Extensions">
 
 	  <t>
 	    Many of the changes listed in <xref target="sect.doclist"
 	    /> require IGP-TE changes, though most are small
 	    extensions to provide additional information.  This set
 	    includes <xref target="r.bundle" />, <xref
-	    target="r.metric" />, <xref target="r.delay" />, <xref
-	    target="r.freq-balance" />, <xref target="r.ll-ul-leak"
-	    />, and <xref target="r.mp-tp" />.  An adjustment to
-	    existing advertised parameters is suggested in <xref
-	    target="r.ip-ldp" />.
+	    target="r.delay" />, <xref target="r.freq-balance" />,
+	    <xref target="r.ll-ul-leak" />, and <xref target="r.mp-tp"
+	    />.  An adjustment to existing advertised parameters is
+	    suggested in <xref target="r.ip-ldp" />.
 	  </t>
 
 	</section>
 
 	<section anchor="sect.by-pw-extn"
 		 title="PW Protocol Extensions">
 
 	  <t>
 	    The only suggestion of pseudowire (PW) extensions is in
 	    <xref target="r.pw-extn" />.
 	  </t>
 
 	</section>
 
 	<section anchor="sect.by-ldp-extn"
 		 title="LDP Protocol Extensions">
 
 	  <t>
 	    Potential LDP extensions are described in <xref
 	    target="r.ldp-extn" />.
 	  </t>
 
 	</section>
 
 	<section anchor="sect.by-rsvp-te"
 		 title="RSVP-TE Protocol Extensions">
 
 	  <t>
 	    RSVP-TE protocol extensions are called for in <xref
-	    target="r.bundle" />, <xref target="r.metric" />, <xref
-	    target="r.freq-balance" />, <xref target="r.mp-tp" />, and
-	    <xref target="r.symmetry" />.
+	    target="r.bundle" />, <xref target="r.freq-balance" />,
+	    <xref target="r.mp-tp" />, and <xref target="r.symmetry"
+	    />.
 	  </t>
 
 	</section>
 
 	<section anchor="sect.by-path-select"
 		 title="RSVP-TE Path Selection Changes">
 
 	  <t>
 	    <xref target="r.path" /> calls for path selection to be
 	    addressed in individual documents that require change.
 	    These changes would include those proposed in <xref
-	    target="r.bundle" />, <xref target="r.metric" />, <xref
+	    target="r.bundle" />, <xref
 	    target="r.delay" />, <xref target="r.freq-balance" />, and
 	    <xref target="r.mp-tp" />.
 	  </t>
 
 	</section>
 
 	<section anchor="sect.by-ac"
 		 title="RSVP-TE Admission Control and Preemption">
 
 	  <t>
 	    When a change is needed to path selection, a corresponding
 	    change is needed in admission control.  The same set of
 	    sections applies: <xref target="r.bundle" />, <xref
-	    target="r.metric" />, <xref target="r.delay" />, <xref
-	    target="r.freq-balance" />, and <xref target="r.mp-tp" />.
-	    Some resource changes such as a link delay change might
-	    trigger preemption.  The rules of preemption remain
-	    unchanged, still based on holding priority.
+	    target="r.delay" />, <xref target="r.freq-balance" />, and
+	    <xref target="r.mp-tp" />.  Some resource changes such as
+	    a link delay change might trigger preemption.  The rules
+	    of preemption remain unchanged, still based on holding
+	    priority.
 	  </t>
 
 	</section>
 
 	<section anchor="sect.by-forwarding"
 		 title="Flow Identification and Traffic Balance">
 
 	  <t>
 	    The following describe either the state of the art in flow
 	    identification and traffic balance or propose changes:
 	    <xref target="r.adaptive" />, <xref
 	    target="r.freq-balance" />, <xref target="r.mp-tp" />, and
 	    <xref target="r.disrupt" />.
 	  </t>
 
 	</section>
 
       </section>
 
     </section>