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 protected]
+
+ > 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:
793f49ba1fc821409f99f10862a0e4db06827...@fhdp1lumxcv14.us.one.verizon.com
+
+ 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 protected]>
+
+ 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 protected]>
+
+ 05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon
+ Message-ID: <[email protected]>
+
+ 05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon
+ Message-ID: <[email protected]>
+
+ 05/24 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon
+ Message-Id: <[email protected]>
+
+ 05/24 Kireeti Kompella Re: change to requirements (was Re: draft-so-yon
+ Message-ID: <[email protected]>
+
+ 05/24 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon
+ Message-Id: <[email protected]>
+
+ 05/24 Iftekhar Hussain RE: change to requirements (was Re: draft-so-yon
+ Message-ID:
<d7d7ab44c06a2440b716f1f1f5e70ae534655...@sv-exdb-prod1.infinera.com>
+
+ 06/01 Curtis Villamizar Re: change to requirements (was Re: draft-so-yon
+ Message-Id: <[email protected]>
+
+ 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 protected]</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 protected]</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 -
- <vspace blankLines="1" /> 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>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
