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.
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>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
