This is part 2 of 3 parts. Please send responses as replies to part 1.
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 @@ -14,9 +14,12 @@ <!ENTITY RFC2991 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2991.xml";> <!ENTITY RFC2992 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2992.xml";> <!ENTITY RFC3031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3031.xml";> + <!ENTITY RFC3032 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.xml";> + <!ENTITY RFC3209 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3209.xml";> + <!ENTITY RFC3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml";> <!ENTITY RFC3468 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3468.xml";> <!ENTITY RFC3809 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3809.xml";> - <!ENTITY RFC3260 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml";> + <!ENTITY RFC3985 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3985.xml";> <!ENTITY RFC4031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4031.xml";> <!ENTITY RFC4201 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4201.xml";> <!ENTITY RFC4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml";> @@ -28,11 +31,15 @@ <!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4762.xml";> <!ENTITY RFC4797 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4797.xml";> <!ENTITY RFC4928 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4928.xml";> + <!ENTITY RFC5036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5036.xml";> <!ENTITY RFC5254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5254.xml";> + <!ENTITY RFC5921 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5921.xml";> -<!ENTITY I-D.ietf-pwe3-fat-pw SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-pwe3-fat-pw-03.xml";> -<!ENTITY I-D.ietf-l2vpn-vpms-frmwk-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l2vpn-vpms-frmwk-requirements-03.xml";> +<!ENTITY I-D.ietf-l2vpn-vpms-frmwk-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-l2vpn-vpms-frmwk-requirements-04";> +<!ENTITY I-D.symmvo-rtgwg-cl-use-cases SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-symmvo-rtgwg-cl-use-cases-00";> + +<!ENTITY I-D.so-yong-rtgwg-cl-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-so-yong-rtgwg-cl-framework-05";> ]> @@ -47,14 +54,112 @@ <?rfc comments="yes"?> <?rfc inline="yes" ?> -<!-- we have lost some comments and some changes based on email message: +<!-- + + 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. + + 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> - - -<!-- - <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 --> @@ -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"> @@ -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 @@ -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> @@ -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> <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 @@ -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"> @@ -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> + <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 @@ -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> @@ -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"> @@ -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 @@ -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 @@ -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 @@ -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> @@ -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 @@ -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> @@ -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> @@ -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> @@ -727,20 +829,20 @@ <references title="Informative References"> - &RFC2702; - &RFC3031; + &RFC3032; + + &RFC3209; + &RFC3468; - &RFC3809; + &RFC3985; &RFC4031; &RFC4364; - &RFC4665; - &RFC4664; &RFC4761; @@ -749,10 +851,16 @@ &RFC4797; - &RFC5254; + &RFC5036; + + &RFC5921; &I-D.ietf-l2vpn-vpms-frmwk-requirements; + &I-D.symmvo-rtgwg-cl-use-cases; + + &I-D.so-yong-rtgwg-cl-framework; + <reference anchor="ITU-T.G.800" target="http://www.itu.int/rec/T-REC-G/recommendation.asp?parent=T-REC-G.800";> <front> @@ -769,57 +877,6 @@ </references> - <references title="Appendix References"> - <!-- add diffserv framework --> - - &RFC1717; - - &RFC2475; - - &RFC2615; - - &RFC2991; - - &RFC2992; - - &RFC3260; - - &RFC4201; - - &RFC4301; - - &RFC4385; - - &RFC4928; - - &I-D.ietf-pwe3-fat-pw; - - </references> - - <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> @@ -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
