CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework)
Curtis Villamizar <curtis@occnc.com> Wed, 20 June 2012 16:39 UTC
Return-Path: <curtis@occnc.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2DD21F8745 for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 09:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.32
X-Spam-Level:
X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=-1.320, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyVUiLE-f4Rv for <rtgwg@ietfa.amsl.com>; Wed, 20 Jun 2012 09:39:49 -0700 (PDT)
Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 1E80E21F8743 for <rtgwg@ietf.org>; Wed, 20 Jun 2012 09:39:49 -0700 (PDT)
Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q5KGdU6J074798; Wed, 20 Jun 2012 09:39:31 -0700 (PDT) (envelope-from curtis@occnc.com)
Message-Id: <201206201639.q5KGdU6J074798@gateway.ipv6.occnc.com>
To: Iftekhar Hussain <IHussain@infinera.com>
Subject: CL frameword xref diffs (was: Re: draft-so-yong-rtgwg-cl-framework)
From: Curtis Villamizar <curtis@occnc.com>
Date: Wed, 20 Jun 2012 12:39:30 -0400
Cc: RTGWG <rtgwg@ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jun 2012 16:39:51 -0000
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>
- CL frameword xref diffs (was: Re: draft-so-yong-r… Curtis Villamizar
- RE: CL frameword xref diffs (was: Re: draft-so-yo… Iftekhar Hussain