From IHussain@infinera.com Fri Apr 13 14:16:58 2012 Return-Path: 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 A65C811E8119 for ; Fri, 13 Apr 2012 14:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.559 X-Spam-Level: X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=2.039, BAYES_00=-2.599, HTML_MESSAGE=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 sbSG9wnAzy+1 for ; Fri, 13 Apr 2012 14:16:56 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 99DDB11E8115 for ; Fri, 13 Apr 2012 14:16:56 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.01.0355.002; Fri, 13 Apr 2012 14:16:55 -0700 From: Iftekhar Hussain To: "rtgwg@ietf.org" Subject: Ref: Composite link drafts update and request Thread-Topic: Ref: Composite link drafts update and request Thread-Index: Ac0ZmzIXk41mxbnyQW255amlyyt/Ug== Date: Fri, 13 Apr 2012 21:16:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE5345CAA53SVEXDBPROD1infi_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 21:16:58 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE5345CAA53SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have following clarification questions/comments about the https://tools.i= etf.org/html/draft-ietf-rtgwg-cl-requirement-05 document a) Section 3. "Examples of a physical link are: Lambda, Ethernet PHY, = and OTN". Should "OTN" be "OTU"? Furthermore, can a "component link" be formed by = set of Lambda? b) Section 4.1. In the context of "FR#1" from end-to-end perspective,= should there be some sort of network scale related requirement(s)? For exa= mple, max number of pair of nodes connected via composite links traversed e= tc. If this aspect is covered somewhere a reference should be added. c) Section 4.2, "Communication of other performance parameters (e.g.= , delay variation) is desirable" seems to contradict "FR#17" in section 4.3= . d) Section 4.2, FR#8" appears to use "latency" in the end-to-end sense= . While the next requirement "FR#9" appears to refer to this term only bet= ween two nodes. I think, it would helpful to clarify the usage of term "lat= ency" e.g., what component of a node transit delay it excludes or includes.= Or add a reference to a document if this is covered in some other document= . e) General comment section 4.3. "Many techniques have been developed t= o balance the distribution of flows across component links that connect th= e same pair of nodes" and "...via composite links, other techniques have b= een developed." It would good to add a reference(s) for each. f) Section 4.3, "FR#12" is about latency while the example "...a use= r experience objective (e.g. jitter buffer under/overrun)" appears to refe= r to delay variation. I think, the example should be consistent with the re= quirement. g) Section 4.3, "FR#17". It is not clear why the delay variation is co= nsidered in this context. Reading this requirement, one gets the impressio= n as if the composite link delay has two components (delay and delay variat= ion). I had understood that delay variation (contributed through the nodal = switching/queuing delays) is not considered in this document. h) DR#6, a minor typo "Solution" should be "solution"? Thanks, Iftekhar "As was discussed in yesterday's rtgwg meeting, there are three composite link drafts: https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 https://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05 https://tools.ietf.org/html/draft-symmvo-rtgwg-cl-use-cases-00 You can read the slides I presented on these drafts at https://tools.ietf.org/agenda/83/slides/slides-83-rtgwg-3.pdf (it's a quick read!). As Alia said, you are all requested to read and comment on these drafts. In about a month's time, we will be requesting WG adoption of draft-so and draft-symmvo, and it'll be great to have an informed discussion at that time. Thanks much, Andy" --_000_D7D7AB44C06A2440B716F1F1F5E70AE5345CAA53SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have following clarification questions/comments ab= out the https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 document=

 

a)      Section 3. “Examples of a physical link are: = Lambda, Ethernet PHY, and OTN”.

 Should “OTN&#= 8221; be “OTU”?  Furthermore, can a “component link&= #8221;  be formed by set of Lambda?

b)      Section 4.1.  In the context of “FR#1= 221; from end-to-end perspective, should there be some sort of network scal= e related requirement(s)? For example, max number of pair of nodes connecte= d via composite links traversed etc. If this aspect is covered somewhere a reference should be added.

c)     &= nbsp; Section 4.2, “Communication of other  pe= rformance parameters (e.g., delay variation) is desirable” seems to c= ontradict “FR#17” in section 4.3.

d)      Section 4.2, FR#8” appears to use “late= ncy” in the end-to-end sense.  While the next requirement “= ;FR#9” appears to refer to this term only between two nodes. I think,= it would helpful to clarify the usage of term “latency” e.g., = what component of a node transit delay it excludes or includes. Or add a refere= nce to a document if this is covered in some other document.

e)      General comment section 4.3. “Many techniques= have been developed to balance the distribution of flows across component = links that  connect the same pair of nodes” and “…vi= a composite links,  other techniques have been developed.” It would good to add a reference(s) for each.

f)     &= nbsp; Section 4.3,  “FR#12” is about lat= ency while the example “…a user experience  objective (e.g= . jitter buffer under/overrun)” appears to refer to delay variation. = I think, the example should be consistent with the requirement.<= /p>

g)      Section 4.3, “FR#17”. It is not clear w= hy the delay variation is considered in this context. Reading this requirem= ent,  one gets the impression as if the composite link delay has two c= omponents (delay and delay variation). I had understood that delay variation (contributed through the nodal switching/queuing dela= ys) is not considered in this document.

h)      DR#6, a minor typo “Solution” should be= “solution”?

 

Thanks,

Iftekhar

 

“As was discussed in yesterday's rtgwg meeting= , there are three

composite link drafts:

 

https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requ= irement-05

 

https://tools.ietf.org/html/draft-so-yong-rtgwg-cl-f= ramework-05

 

https://tools.ietf.org/html/draft-symmvo-rtgwg-cl-us= e-cases-00

 

You can read the slides I presented on these drafts = at

https://tools.ietf.org/agenda/83/slides/slides-83-rt= gwg-3.pdf (it's a

quick read!).

 

As Alia said, you are all requested to read and comm= ent on these

drafts. In about a month's time, we will be requesti= ng WG adoption of

draft-so and draft-symmvo, and it'll be great to hav= e an informed

discussion at that time.

 

Thanks much,

Andy”

 

--_000_D7D7AB44C06A2440B716F1F1F5E70AE5345CAA53SVEXDBPROD1infi_-- From curtis@occnc.com Thu Apr 19 19:09:49 2012 Return-Path: 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 9F8FB21F867C for ; Thu, 19 Apr 2012 19:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9k0wKjEJSnAS for ; Thu, 19 Apr 2012 19:09:48 -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 277A221F8678 for ; Thu, 19 Apr 2012 19:09:47 -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 q3K29ien077934; Thu, 19 Apr 2012 19:09:44 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201204200209.q3K29ien077934@gateway.ipv6.occnc.com> To: Iftekhar Hussain From: Curtis Villamizar Subject: Re: Ref: Composite link drafts update and request In-reply-to: Your message of "Fri, 13 Apr 2012 21:16:55 -0000." Date: Thu, 19 Apr 2012 22:09:44 -0400 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:09:49 -0000 Iftekhar, Responses inline. Some reformating of your email into plain text. Thanks for the interest and for the comments. Curtis In message Iftekhar Hussain writes: > Hi, > > I have following clarification questions/comments about the > https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 > document > > a) Section 3. "Examples of a physical link are: Lambda, Ethernet PHY, > and OTN". Should "OTN" be "OTU"? Furthermore, can a "component > link" be formed by set of Lambda? We are mixing physical and physical plus link layer in the examples. The distinction is not important in this context but if you feel strongly we could clarify. If we put ODU then others would complain that ODU is carried in OTU and then we run into the issue that OTU is a framing on an OPU and perhaps someone would argue that OTU is not a physical layer and that even OPU is not truly a physical layer. It might be best to change this to: Examples of a physical link (physical layer plus link layer) are: a lambda with any link layer(s), Ethernet, OTN. Examples of multiple link layers include POS/SONET, 10GbE/ODU2e/ODU4/OTU4/OPU4, etc. In the same way, WDM could be considered an example of multiple physical layers (the individual lambda multiplex using WDM). The problem is that any attempt to strictly apply the antiquated ISO 7-layer model falls apart even is we apply only the physical layer and link layer. For WDM we have the physical layer subdivided into a layer zero (optical) and a layer one (modulated signal aka single lambda). We have plenty of examples of multiple link layer (layer two) protocols. The important distinction is [CL running over] a physical link plus link layer [used as a component link] vs [CL running over] MPLS [used as a component link]. Rewritten without the []: The important distinction is a physical link plus link layer vs MPLS. > b) Section 4.1. In the context of "FR#1" from end-to-end perspective, > should there be some sort of network scale related requirement(s)? > For example, max number of pair of nodes connected via composite > links traversed etc. If this aspect is covered somewhere a > reference should be added. End-to-end in any MPLS context means edge-to-edge (and is not mentioned at all in FR#1 or elsewhere). Existing scaling techniques used in MPLS networks still apply. Scaling is the motivation for DR#5 (IGP extensions disallowed in multiple domain case). Scaling is directly addressed in DR#6 (fast convergence) and DR#7 (fast worst case failure convergence). Scalability and stability are covered in the framework document (draft-so-yong-rtgwg-cl-framework). For example in "3.1. Scalability Motivations" and "3.5. Avoiding Route Oscillation". Possible need for further work is suggested in "7.2.11. Performance, Scalability, and Stability" in the framework document. > c) Section 4.2, "Communication of other performance parameters (e.g., > delay variation) is desirable" seems to contradict "FR#17" in > section 4.3. The statement is: [...] Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable. If jitter was described as "undesireable" then it might be a contradiction. The point is delay is very important and delay variation would be nice (maybe not IMHO). What is important (ie: normative) is what the implementation MUST support, and what the operator MAY enable or disable. What is unimportant is subjective verbiage about relative importance among parameters. The operator will decide what is important by using or not using a feature. FR#17 says: FR#17 The solution SHALL provide a means to indicate that a traffic flow shall select a component link with a maximum acceptable delay variation value as specified by protocol. There are two differences between the statement in Section 4.2 and the statement in FR#17. First "communication of other performance parameters" and "provide a means to indicate that a traffic flow shall select a component link with a maximum acceptable delay variation value" are two different things; the first is a IGP parameter (link delay or link delay variation), the second is an RSVP parameter (maximum allowable delay variation for a given LSP). Second, the wording in Section 4.2 is informative and the wording in FR#17 is normative. > d) Section 4.2, FR#8" appears to use "latency" in the end-to-end > sense. While the next requirement "FR#9" appears to refer to this > term only between two nodes. I think, it would helpful to clarify > the usage of term "latency" e.g., what component of a node transit > delay it excludes or includes. Or add a reference to a document if > this is covered in some other document. BTW- I prefer delay over latency, but the term latency is used. The two mean the same thing. Neither word by itself does not indicate any one type of delay (fabric delay, transmit delay, queuing delay, geographic delay). Neither word by itself implies intra-node delay, or delay between adjacent nodes, or end-to-end delay. FR#8 applies to any measurement of delay, whether it is a measurement over a single physical link or over a component link carried over a multihop MPLS LSP. Also in FR#9 there is no indication that the nodes are adjacent, and the phrase "when the path between these nodes contains one or more pairs of nodes connected via a composite link" clearly indicates that multihop paths are being considered as well as delay between adjacent nodes. There are some hints as to which delays the operators may consider important in this context. FR#8 states that "The precision of latency reporting SHOULD be at least 10% of the one way latencies for latency of 1 ms or more." This excludes most equipment latencies which can be expected to be well under 100 usec (10% of 1 msec). The intent is to measure the predominant latency in most (well run) service provider networks, which is geographic delay on the order of msec or tens of msec and in some cases over 100 msec (intercontinental traffic). In a congested network (possibly not so well run network, or maybe a well run network with a substantial outage) queuing delay can be quite large. In a congested network measuring the queuing delay for the low priority traffic (the only traffic likely to be experiencing congestion, even in an outage) is more likely to add to problems by adding routing instability. The only real question in FR#8 and FR#9 is whether queuing delay is counted in the latency figure. 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. There are quite a few documents that deal with this tradeoff. For example, in MPLS-TP it is noted that delay measurements should be made using the highest priority COS value (which in effect very nearly eliminates any queuing delay from the measurement). For the requirements document, this tradeoff is not discussed, however the stability and convergence requirements must be considered when coming up with a solution. Solutions should be described in the framework document and not in the requirments document. In the framework document (draft-so-yong-rtgwg-cl-framework) there is discussion of this tradeoff in "3.5. Avoiding Route Oscillation" and elsewhere. The framework document is a better place for discussion of requirements tradeoffs. > e) General comment section 4.3. "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." It would good to add a > reference(s) for each. There are a few RFCs on the topic. Inverse multiplexing, various forms of ECMP, and Ethernet Link Aggregation are all well known. The statement would certainly not be controversial without references. If you are looking for further information on this, the Use Cases draft (draft-symmvo-rtgwg-cl-use-cases) has references. "Appendix B. Existing Multipath Standards and Techniques" was moved from the requirements document to the Use Cases draft. We could add a reference to the use cases draft in the requirements draft if you think that would help. > f) Section 4.3, "FR#12" is about latency while the example "...a user > experience objective (e.g. jitter buffer under/overrun)" appears to > refer to delay variation. I think, the example should be consistent > with the requirement. The requirement in FR#12 is in the first paragraph. FR#12 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. The rest is discussion. 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). The discussion exists primarily for the reader who might otherwise not realize why there would be a disruption at all (and therefore might not understand why we have to say "minimally disruptive" instead of "completely non-disruptive"). Perhaps the entire paragraph needs to start with "For example, [...]". In any case it is not inconsistent. When delay changes on the current big-bad-Internet (such as in VOIP), the change is often absorbed by a jitter buffer as long as the change is small. If a delay change of many milliseconds occurs, then it is unlikely that the typical relatively small jitter buffer can hide the delay change. > g) Section 4.3, "FR#17". It is not clear why the delay variation is > considered in this context. Reading this requirement, one gets the > impression as if the composite link delay has two components (delay > and delay variation). I had understood that delay variation > (contributed through the nodal switching/queuing delays) is not > considered in this document. FR#16 is about delay. FR#17 is about delay variation. The wording "The solution SHALL provide a means" doesn't require the operator to use that feature. Therefore it is better to keep the two in separate requirements as it is more clear that one could be enabled and the other disabled. > h) DR#6, a minor typo "Solution" should be "solution"? Thanks for pointing this out. > Thanks, > Iftekhar > > > As was discussed in yesterday's rtgwg meeting, there are three > > composite link drafts: > > > > https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 > > > > https://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05 > > > > https://tools.ietf.org/html/draft-symmvo-rtgwg-cl-use-cases-00 > > > > You can read the slides I presented on these drafts at > > https://tools.ietf.org/agenda/83/slides/slides-83-rtgwg-3.pdf (it's a > > quick read!). > > > > As Alia said, you are all requested to read and comment on these > > drafts. In about a month's time, we will be requesting WG adoption of > > draft-so and draft-symmvo, and it'll be great to have an informed > > discussion at that time. > > > > Thanks much, > > Andy From IHussain@infinera.com Mon Apr 23 10:51:54 2012 Return-Path: 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 45B0D21F84EE for ; Mon, 23 Apr 2012 10:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[AWL=1.020, BAYES_00=-2.599] 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 xqF+xTJhfEyg for ; Mon, 23 Apr 2012 10:51:53 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id EB62521F84EB for ; Mon, 23 Apr 2012 10:51:52 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0247.003; Mon, 23 Apr 2012 10:51:51 -0700 From: Iftekhar Hussain To: "curtis@occnc.com" Subject: RE: Ref: Composite link drafts update and request Thread-Topic: Ref: Composite link drafts update and request Thread-Index: AQHNHpqrsW4uFBDqzkOEmpAl+Njq6paorGlA Date: Mon, 23 Apr 2012 17:51:51 +0000 Message-ID: References: Your message of "Fri, 13 Apr 2012 21:16:55 -0000." <201204200209.q3K29ien077934@gateway.ipv6.occnc.com> In-Reply-To: <201204200209.q3K29ien077934@gateway.ipv6.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:51:54 -0000 Curtis, Please see comments inline.=20 Thanks for the detailed responses. Iftekhar -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Thursday, April 19, 2012 7:10 PM To: Iftekhar Hussain Cc: rtgwg@ietf.org Subject: Re: Ref: Composite link drafts update and request Iftekhar, Responses inline. Some reformating of your email into plain text. Thanks for the interest and for the comments. Curtis In message Iftekhar Hussain writes: =20 > Hi, > =20 > I have following clarification questions/comments about the > https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 > document > =20 > a) Section 3. "Examples of a physical link are: Lambda, Ethernet PHY, > and OTN". Should "OTN" be "OTU"? Furthermore, can a "component > link" be formed by set of Lambda? We are mixing physical and physical plus link layer in the examples. The distinction is not important in this context but if you feel strongly w= e could clarify. If we put ODU then others would complain that ODU is carried in OTU and the= n we run into the issue that OTU is a framing on an OPU and perhaps someone= would argue that OTU is not a physical layer and that even OPU is not trul= y a physical layer. [Iftekhar] Yes the main confusion was it was specifically referring to phys= ical links. Your suggested change will help it clarify. It might be best to change this to: Examples of a physical link (physical layer plus link layer) are: a lambda with any link layer(s), Ethernet, OTN. Examples of multiple link layers include POS/SONET, 10GbE/ODU2e/ODU4/OTU4/O= PU4, etc. In the same way, WDM could be considered an example of multiple = physical layers (the individual lambda multiplex using WDM). The problem i= s that any attempt to strictly apply the antiquated ISO 7-layer model falls= apart even is we apply only the physical layer and link layer. For WDM we= have the physical layer subdivided into a layer zero (optical) and a layer= one (modulated signal aka single lambda). We have plenty of examples of m= ultiple link layer (layer two) protocols. The important distinction is [CL running over] a physical link plus link la= yer [used as a component link] vs [CL running over] MPLS [used as a compone= nt link]. Rewritten without the []: The important distinction is a physica= l link plus link layer vs MPLS. > b) Section 4.1. In the context of "FR#1" from end-to-end perspective, > should there be some sort of network scale related requirement(s)? > For example, max number of pair of nodes connected via composite > links traversed etc. If this aspect is covered somewhere a > reference should be added. End-to-end in any MPLS context means edge-to-edge (and is not mentioned at = all in FR#1 or elsewhere). Existing scaling techniques used in MPLS networ= ks still apply. Scaling is the motivation for DR#5 (IGP extensions disallo= wed in multiple domain case). Scaling is directly addressed in DR#6 (fast = convergence) and DR#7 (fast worst case failure convergence). Scalability and stability are covered in the framework document (draft-so-y= ong-rtgwg-cl-framework). For example in "3.1. Scalability Motivations" an= d "3.5. Avoiding Route Oscillation". Possible need for further work is su= ggested in "7.2.11. Performance, Scalability, and Stability" in the framew= ork document. [Iftekhar] Okay. I will take a look at the " draft-so-yong-rtgwg-cl-framewo= rk". You might consider adding a reference to the framework document. > c) Section 4.2, "Communication of other performance parameters (e.g., > delay variation) is desirable" seems to contradict "FR#17" in > section 4.3. The statement is: [...] Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable. If jitter was described as "undesireable" then it might be a contradiction.= The point is delay is very important and delay variation would be nice (m= aybe not IMHO). What is important (ie: normative) is what the implementation MUST support, and what the operator M= AY enable or disable. What is unimportant is subjective verbiage about rel= ative importance among parameters. The operator will decide what is import= ant by using or not using a feature. FR#17 says: FR#17 The solution SHALL provide a means to indicate that a traffic flow shall select a component link with a maximum acceptable delay variation value as specified by protocol. There are two differences between the statement in Section 4.2 and the stat= ement in FR#17. First "communication of other performance parameters" and = "provide a means to indicate that a traffic flow shall select a component l= ink with a maximum acceptable delay variation value" are two different thin= gs; the first is a IGP parameter (link delay or link delay variation), the = second is an RSVP parameter (maximum allowable delay variation for a given = LSP). Second, the wording in Section 4.2 is informative and the wording in= FR#17 is normative. [Iftekhar] Okay. I interpreted jitter as "desirable" meaning it is an objec= tive i.e., it is not required. But then saw the requirement FR#17 which I r= ead as a requirement to support delay variation. For example in FR#17 I wa= s expecting "MAY" or "SHOULD" rather than "MUST".=20 > d) Section 4.2, FR#8" appears to use "latency" in the end-to-end > sense. While the next requirement "FR#9" appears to refer to this > term only between two nodes. I think, it would helpful to clarify > the usage of term "latency" e.g., what component of a node transit > delay it excludes or includes. Or add a reference to a document if > this is covered in some other document. BTW- I prefer delay over latency, but the term latency is used. The two me= an the same thing. Neither word by itself does not indicate any one type o= f delay (fabric delay, transmit delay, queuing delay, geographic delay). N= either word by itself implies intra-node delay, or delay between adjacent n= odes, or end-to-end delay. FR#8 applies to any measurement of delay, whether it is a measurement over = a single physical link or over a component link carried over a multihop MPL= S LSP. Also in FR#9 there is no indication that the nodes are adjacent, an= d the phrase "when the path between these nodes contains one or more pairs = of nodes connected via a composite link" clearly indicates that multihop paths are being considered as well as delay= between adjacent nodes. There are some hints as to which delays the operators may consider importan= t in this context. FR#8 states that "The precision of latency reporting SH= OULD be at least 10% of the one way latencies for latency of 1 ms or more."= This excludes most equipment latencies which can be expected to be well u= nder 100 usec (10% of 1 msec). The intent is to measure the predominant latency in most (well run) service= provider networks, which is geographic delay on the order of msec or tens = of msec and in some cases over 100 msec (intercontinental traffic). In a c= ongested network (possibly not so well run network, or maybe a well run net= work with a substantial outage) queuing delay can be quite large. In a con= gested network measuring the queuing delay for the low priority traffic (th= e only traffic likely to be experiencing congestion, even in an outage) is = more likely to add to problems by adding routing instability. The only real question in FR#8 and FR#9 is whether queuing delay is counted= in the latency figure. The argument for including queuing delay is that i= t reflects the delay experienced by applications. The argument against inc= luding queuing delay is that it if used in routing decisions it can result = in routing instability. There are quite a few documents that deal with this tradeoff. For example,= in MPLS-TP it is noted that delay measurements should be made using the hi= ghest priority COS value (which in effect very nearly eliminates any queuin= g delay from the measurement). For the requirements document, this tradeoff is not discussed, however the = stability and convergence requirements must be considered when coming up wi= th a solution. Solutions should be described in the framework document and= not in the requirments document. In the framework document (draft-so-yong-rtgwg-cl-framework) there is discu= ssion of this tradeoff in "3.5. Avoiding Route Oscillation" and elsewhere.= The framework document is a better place for discussion of requirements t= radeoffs. [Iftekhar] Okay, will take a look at the framework document.=20 > e) General comment section 4.3. "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." It would good to add a > reference(s) for each. There are a few RFCs on the topic. Inverse multiplexing, various forms of = ECMP, and Ethernet Link Aggregation are all well known. The statement woul= d certainly not be controversial without references. If you are looking for further information on this, the Use Cases draft (dr= aft-symmvo-rtgwg-cl-use-cases) has references. "Appendix B. Existing Multipath Standards and Techniques" was moved from the requirement= s document to the Use Cases draft. We could add a reference to the use cases draft in the requirements draft i= f you think that would help. [Iftekhar] I believe the requirement document would read better and easier = to follow if the references are added. > f) Section 4.3, "FR#12" is about latency while the example "...a user > experience objective (e.g. jitter buffer under/overrun)" appears to > refer to delay variation. I think, the example should be consistent > with the requirement. The requirement in FR#12 is in the first paragraph. FR#12 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. The rest is discussion. 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). The discussion exists primarily for the reader who might otherwise not real= ize why there would be a disruption at all (and therefore might not underst= and why we have to say "minimally disruptive" instead of "completely non-di= sruptive"). Perhaps the entire paragraph needs to start with "For example,= [...]". In any case it is not inconsistent. When delay changes on the current big-= bad-Internet (such as in VOIP), the change is often absorbed by a jitter bu= ffer as long as the change is small. If a delay change of many millisecond= s occurs, then it is unlikely that the typical relatively small jitter buff= er can hide the delay change. [Iftekhar] Thanks for detailed response. To me then the requirement then is= about change in latency (i.e., delay variation). > g) Section 4.3, "FR#17". It is not clear why the delay variation is > considered in this context. Reading this requirement, one gets the > impression as if the composite link delay has two components (delay > and delay variation). I had understood that delay variation > (contributed through the nodal switching/queuing delays) is not > considered in this document. FR#16 is about delay. FR#17 is about delay variation. The wording "The so= lution SHALL provide a means" doesn't require the operator to use that feat= ure. Therefore it is better to keep the two in separate requirements as it= is more clear that one could be enabled and the other disabled. [Iftekhar] I think it would be clear if somehow the meaning of the above se= ntence "i.e., doesn't require the operator...." is included in the text. > h) DR#6, a minor typo "Solution" should be "solution"? Thanks for pointing this out. > Thanks, > Iftekhar > =20 > > As was discussed in yesterday's rtgwg meeting, there are three=20 > > composite link drafts: > > =20 > > https://tools.ietf.org/html/draft-ietf-rtgwg-cl-requirement-05 > > =20 > > https://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05 > > =20 > > https://tools.ietf.org/html/draft-symmvo-rtgwg-cl-use-cases-00 > > =20 > > You can read the slides I presented on these drafts at=20 > > https://tools.ietf.org/agenda/83/slides/slides-83-rtgwg-3.pdf (it's=20 > > a quick read!). > > =20 > > As Alia said, you are all requested to read and comment on these=20 > > drafts. In about a month's time, we will be requesting WG adoption=20 > > of draft-so and draft-symmvo, and it'll be great to have an informed=20 > > discussion at that time. > > =20 > > Thanks much, > > Andy From alvaro.retana@hp.com Tue Apr 24 14:58:45 2012 Return-Path: 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 BB7D021E8019 for ; Tue, 24 Apr 2012 14:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 i1wHTo3xTUe8 for ; Tue, 24 Apr 2012 14:58:44 -0700 (PDT) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by ietfa.amsl.com (Postfix) with ESMTP id 60A3011E8074 for ; Tue, 24 Apr 2012 14:58:44 -0700 (PDT) Received: from G9W0369G.americas.hpqcorp.net (g9w0369g.houston.hp.com [16.216.193.232]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id C91F8242BA for ; Tue, 24 Apr 2012 21:58:41 +0000 (UTC) Received: from G1W0395.americas.hpqcorp.net (16.236.31.0) by G9W0369G.americas.hpqcorp.net (16.216.193.232) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 24 Apr 2012 21:57:03 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.12]) by G1W0395.americas.hpqcorp.net ([16.236.31.0]) with mapi; Tue, 24 Apr 2012 22:57:03 +0100 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Tue, 24 Apr 2012 22:57:03 +0100 Subject: IETF 83 Minutes Posted Thread-Topic: IETF 83 Minutes Posted Thread-Index: Ac0iZS6ryWbR3u0IRCWo4Vx3BR5cjA== Message-ID: <24646CE17826CF4A8DF71F9856C7E656597EC3C625@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ALFy Af13 CIVo CTXA C2xi EeQk FZCA Gse+ H3f0 INmg IYVM KFkz Khia K4oS LZG8 LfXJ; 1; cgB0AGcAdwBnAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {FAD33F21-F148-4B36-AC5F-83AC1177F3EA}; YQBsAHYAYQByAG8ALgByAGUAdABhAG4AYQBAAGgAcAAuAGMAbwBtAA==; Tue, 24 Apr 2012 21:57:03 GMT;SQBFAFQARgAgADgAMwAgAE0AaQBuAHUAdABlAHMAIABQAG8AcwB0AGUAZAA= x-cr-puzzleid: {FAD33F21-F148-4B36-AC5F-83AC1177F3EA} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E656597EC3C625GVW1338EXAame_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 21:58:45 -0000 --_000_24646CE17826CF4A8DF71F9856C7E656597EC3C625GVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI We just posted the minutes: http://www.ietf.org/proceedings/83/minutes/minu= tes-83-rtgwg.txt Thanks to John Scudder for taking very detailed notes. Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E656597EC3C625GVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

 

We just po= sted the minutes: http://www.ietf.org/proceedings/83/minutes/minutes-83-rt= gwg.txt

 

Thanks to John Scudder for taking very detailed notes.

 

Alva= ro.

= --_000_24646CE17826CF4A8DF71F9856C7E656597EC3C625GVW1338EXAame_-- From IHussain@infinera.com Fri Apr 27 14:55:18 2012 Return-Path: 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 96E8521E8024 for ; Fri, 27 Apr 2012 14:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, HTML_MESSAGE=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 O7H2YDgf2erl for ; Fri, 27 Apr 2012 14:55:15 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 814C221E8018 for ; Fri, 27 Apr 2012 14:55:15 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.02.0247.003; Fri, 27 Apr 2012 14:55:14 -0700 From: Iftekhar Hussain To: "rtgwg@ietf.org" Subject: draft-so-yong-rtgwg-cl-framework Thread-Topic: draft-so-yong-rtgwg-cl-framework Thread-Index: Ac0kvoCQtvgy/t6ERRuRKsTj93FuAw== Date: Fri, 27 Apr 2012 21:55:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_D7D7AB44C06A2440B716F1F1F5E70AE534638F36SVEXDBPROD1infi_" MIME-Version: 1.0 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 21:55:18 -0000 --_000_D7D7AB44C06A2440B716F1F1F5E70AE534638F36SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, Please find below some comments on the http://tools.ietf.org/html/draft-so-= yong-rtgwg-cl-framework-05. ---------------------------- 2.1. Flow Identification "Operator may have other objectives such as ...composite link energy saving= , and etc. These new requirements are described in [I-D.ietf-rtgwg-cl-requi= rement]" Comment: I don't recall any energy saving related requirement (or discussion) in the= [I-D.ietf-rtgwg-cl-requirement. Suggest removing the text "energy saving = etc." 2.2. Composite Link in Control Plane "LDP follows the IGP, therefore failure to forward on the IGP path will of= ten result in loss of connectivity if the IGP adjacency is not withdrawn wh= en an LDP FEC is refused. This is a pathologic case that can occur if LDP = is carried natively and there is a high volume of LDP traffic. This situat= ion can be avoided by carrying LDP within RSVP-TE LSP." Comment: Is it the loss of connectivity referring to LDP control plane connectivity = only or LDP signaled LSP data plane or both? Comment: "Composite link capacity is aggregated capacity and MAY be larger than indi= vidual component link capacity." Composite link aggregate capacity should always be larger than individual c= omponent link capacity. Did I misunderstand? "...1. If no other information is available the largest microflow is bound = by one of the following:" Suggested text: If no other information is available the largest microflow is bound (i.e., = signaling extensions don't indicate a bound) by one of the following: Comment: Section 2.2 provides architectural guidelines e.g., " ...Available capacit= y in other component links MUST be used to carry impacted traffic. The ava= ilable bandwidth after failure MUST be advertised immediately to avoid loop= ed crankback" and provides illustrative examples e.g.,"... no microflow lar= ger than 10 Gb/s will be present on the RSVP-TE LSP that aggregate traffic = across the core, even if the core interfaces are 100 Gb/s interfaces." In contrast, section 2.1 appears to be little bit too vague e.g., " ... tec= hnique of grouping flows, such as hashing on the flow identification criter= ia, becomes essential to reduce the stored state, and is an essential scali= ng technique. Other means of grouping flows may be possible" Suggestion: Add some examples which flow identification scheme to use for composite lin= ks or add a reference to section 4.2 which discusses flow identification tr= ade-offs. 4.1.4. Requirements for Contained LSP Comment: Add reference to specific relevant to requirements in I-D.ietf-rtgwg-cl-req= uirement] similar to section 4.1.2 and 4.1.3. 4.2. Data Plane Challenges Comment: Minor typo: "very course..." should be "very coarse..." Comment: "In practice using the MPLS label stack alone has proven too course to ach= eive a reasonably good load balance, due to bin-packing issues and discrpen= cies between signaled bandwidth and actual traffic loads on LSP." Suggest adding a reference to an IETF standard or best practices document t= hat discusses these issues. Comment: Sections 4.2, 2.1, 2.3, appear to be somewhat redundant. Suggest trimming s= ection 2.1 and absorbing that information in section 4.2. 3. Architecture Tradeoffs Comment: "Composite Link is applicable to large networks, and therefore scalability = must be a major consideration." What is a typical definition of a large network? Suggestion: Add an exampl= e (or a forward reference to section 3.3.1 which has an example) 3.1. Scalability Motivations Comment: "....a large routing change to be accomplished more quickly," What is a typical definition of a large routing change? Suggestion: Add an= example. 7.2.5. Dynamic Multipath Balance Comment: "...uses a course granularity, the adjustments would have to be equally co= urse, in the worst case moving entire LSP" Minor typo "course" should be "coarse". 7. Required Protocol Extensions and Mechanisms Comment/suggestion: Organizing section 7 as a matrix containing something like: Requirement#, = Existing Mechanisms, Gaps, Ongoing/new extensions..., might be more clearer= . AT a minimum, add a traceability to each requirement in [I-D.ietf-rtgwg-c= l-requirement] and the section number in framework document that addresses = each requirement (or set of requirement). Is there a minimal set of requirements which must be met to form a deployab= le (useful) composite link based solution? ----------------------- Regards, Iftekhar --_000_D7D7AB44C06A2440B716F1F1F5E70AE534638F36SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear  Authors,

 

Please find below some comments on the http://tools.ietf.org/html/draft-so-yong-rtgwg-cl-framework-05.

 

----------------------------

2.1. Flow Identification

“Operator may have other objectives such as &#= 8230;composite link energy saving, and etc. These new requirements are desc= ribed in [I-D.ietf-rtgwg-cl-requirement]”

Comment:

I don’t recall any energy saving related requi= rement (or discussion) in the [I-D.ietf-rtgwg-cl-requirement.  Suggest= removing the text “energy saving etc.”

 

2.2. Composite Link in Control Plane

“LDP follows the IGP, therefore failure to for= ward on  the IGP path will often result in loss of connectivity if the= IGP adjacency is not withdrawn when an LDP FEC is refused.  This is a= pathologic case that can occur if LDP is carried natively and there is a high volume of LDP traffic.  This situation c= an be avoided by carrying LDP within RSVP-TE LSP.”

 

Comment:

Is it the loss of connectivity referring to LDP cont= rol plane connectivity only or LDP signaled LSP data plane or both? 

 

Comment:

“Composite link capacity is aggregated capacit= y and MAY be larger than individual component link capacity.”

Composite link aggregate capacity should always be l= arger than individual component link capacity. Did I misunderstand?

 

“…1. If no other information is availabl= e the largest microflow is bound by one of the following:”=

Suggested text:

If no other information is available the largest mic= roflow is bound (i.e., signaling extensions don’t indicate a bound) b= y one of the following:

 

Comment:

Section 2.2 provides architectural guidelines e.g., = “  …Available capacity in other component links MUST be us= ed to carry impacted traffic.  The available bandwidth after failure M= UST be advertised immediately to avoid looped crankback” and provides illustrative examples e.g.,”… no microflow larger= than 10 Gb/s will be present on the RSVP-TE LSP that aggregate traffic acr= oss the core, even if the core interfaces are 100 Gb/s interfaces.”

In contrast, section 2.1 appears to be little bit to= o vague e.g., “ … technique of grouping flows, such as hashing = on the flow identification criteria, becomes essential to reduce the stored= state, and is an essential scaling technique.  Other means of grouping flows may be possible”

Suggestion:

Add some examples which flow identification scheme t= o use for composite links or add a reference to section 4.2 which discusses= flow identification trade-offs.

 

4.1.4. Requirements for Contained LSP

Comment:

Add reference to specific relevant to requirements i= n I-D.ietf-rtgwg-cl-requirement] similar to section 4.1.2 and 4.1.3.

 

4.2. Data Plane Challenges

Comment:

Minor typo: “very course…” should = be “very coarse…”

Comment:

“In practice  using the MPLS label stack = alone has proven too course to acheive a reasonably good load balance, due = to bin-packing issues and discrpencies between signaled bandwidth and actua= l traffic loads on LSP.”

Suggest adding a reference to an IETF standard or be= st practices document that discusses these issues.

 

Comment:

Sections 4.2, 2.1, 2.3, appear to be somewhat redund= ant. Suggest trimming section 2.1 and absorbing that information in section= 4.2.

 

3. Architecture Tradeoffs

Comment:

“Composite Link is applicable to large network= s, and therefore scalability must be a major consideration.”

What is a typical definition of a large network?&nbs= p; Suggestion: Add an example (or a forward reference to section 3.3.1 whic= h has an example)

 

3.1. Scalability Motivations

Comment:

“….a large routing change to be accompli= shed more quickly,”

What is a typical definition of a large routing chan= ge?  Suggestion: Add an example.

 

7.2.5. Dynamic Multipath Balance

Comment:

“…uses a course granularity, the adjustm= ents would have to be equally  course, in the worst case moving entire= LSP”

Minor typo “course” should be “coa= rse”.

 

7. Required Protocol Extensions and Mechanisms<= /o:p>

Comment/suggestion:

Organizing section 7 as  a matrix containing so= mething like: Requirement#, Existing Mechanisms, Gaps, Ongoing/new extensio= ns…, might be more clearer. AT a minimum, add a traceability to each = requirement in [I-D.ietf-rtgwg-cl-requirement] and the section number in framework document that addresses each requireme= nt (or set of requirement).

 

Is there a minimal set of requirements which must be= met to form a deployable (useful) composite link based solution?

 

-----------------------

 

Regards,

Iftekhar

 

--_000_D7D7AB44C06A2440B716F1F1F5E70AE534638F36SVEXDBPROD1infi_--