In message <[email protected]> Lou Berger writes: > > Hi Curtis, > Thanks for the response. See below
You pointed out a a few things you thought should be changed but left it open for me to propose how to change things, so we'll need at least one more iteration after this. > On 1/6/2014 12:00 PM, Curtis Villamizar wrote: > > Lou et al, > > > > Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went > > through to all recipients. There may have been a problem (due to a > > self inflicted DNS issue). > > > > I did not get a response so I suspect Lou didn't get this email. > > > > Curtis FYI - most recent issue I found was an error in IN TXT v=spf1 line. It might be a bad time to be experimenting with IPv6 transition technologies and their effects of email. :-( Go back to plain old dual stack and burn another IPv4 global? Might be the right move. Hopefully mail will get through to everyone now without a resend. If I have to resend I'll put the IPv6 mail server back into the DS subnet before resending. Curtis > > In message <[email protected]> > > Lou Berger writes: > >> > >> Hello, > >> > >> I have been selected as the Routing Directorate reviewer for this draft. > >> The Routing Directorate seeks to review all routing or routing-related > >> drafts as they pass through IETF last call and IESG review. The purpose > >> of the review is to provide assistance to the Routing ADs. For more > >> information about the Routing Directorate, please see > >> http://www.ietf.org/iesg/directorate/routing.html > >> > >> Although these comments are primarily for the use of the Routing ADs, it > >> would be helpful if you could consider them along with any other IETF > >> Last Call comments that you receive, and strive to resolve them through > >> discussion or by updating the draft. > >> > >> Document: draft-ietf-rtgwg-cl-requirement-13.txt > >> Reviewer: Lou Berger > >> Review Date: 2013-12-11 > >> IETF LC End Date: 2013-12-09 > >> Intended Status: Informational > >> > >> Summary: > >> > >> I have some minor concerns about this document that I think > >> should be resolved before publication. > >> > >> Comments: > >> > >> I think the document is greatly improved since the previous last > >> call. I have some comments and reservations on the document that are > >> described below. As discussed on the list, I remain concerned about the > >> value of defining requirements in terms of nebulous "Performance > >> Objectives", but as this is acceptable to the WG I will not elaborate on > >> this concern further. > >> > >> Major Issues: > >> > >> No major issues found. > >> > >> Minor Issues: > >> > >> 1. Terminology & consistency: the document coins the term "Advanced > >> Multipath": > >> Advanced Multipath is a formalization of multipath techniques > >> > >> Do you see this term as a new noun, like LSP, or as an adjective? I > >> expected the latter, i.e. that it be used like "multipath" is used in > >> the above sentence, but it seems to be used as a new noun. I'm not sure > >> coining a new noun really makes sense, but if this the intent then the > >> last paragraph of section 2 needs to be revised as "Advanced Multipath" > >> will now have a specific definition as opposed to a generic term. Also I > >> suggest always capitalizing it (or even using the abbreviation "AM") > >> will clarify this distinction. > > > > I see multipath as a noun and therefore advanced multipath as a noun. > > Advanced is an adjective, multipath as a noun. Advanced Multipath is > > the set of techniques that form a solution. An advanced multipath is > > a collection of componet links. The former is capitalized, the latter > > is not. I'll check to see if I got that right in all occurances. If > > you would like I can also add this to the definition making it: > > > > OLD > > > > Advanced Multipath > > Advanced Multipath meets the requirements defined in this > > document. A key capability of advanced multipath is the support > > of non-homogeneous component links. > > > > NEW > > > > Advanced Multipath > > Advanced Multipath is a formalization of multipath techniques > > that meets the requirements defined in this document. A key > > capability of Advanced Multipath is the support of > > non-homogeneous component links. > > Okay. Then I suggest using "AM" will help delineate this usage. Later you indicate you prefer we don't use the same term. Suggestion follows that. > > An "advanced multipath" is a > > collection of component links. In this document the former is > > capitalized and the latter is not. > > > > If we agree on this I'll just search for "advanced" and make > > capitalization consistent with the above statements. > > the distinction based on capitalization seems likely to introduce > confusion in this document and in future uses, so I think it is a really > bad idea. Clarity is good. If it lacks clarity we'll have to fix it. > > I don't think the phrase "advanced multipath technique" makes it an > > adjective any more than a statement such as make-before-break is an > > MPLS technique" makes MPLS an adjective in normal use. The phrase "an > > X technique" is simply a shorthand for indicating a "technique > > applicable to X". Even if that makes it an adjective the phrase "MPLS > > technique" is common and so that should not be a problem. The > > paragraph in question might be the following. It seems benign to me. > > > > The term Advanced Multipath is intended to be used within the context > > of this document and the related documents, > > [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and > > any other related document. Other advanced multipath techniques may > > in the future arise. If the capabilities defined in this document > > become commonplace, they would no longer be considered "advanced". > > Use of the term "advanced multipath" outside this document, if > > referring to the term as defined here, should indicate Advanced > > Multipath as defined by this document, citing the current document > > name. If using another definition of "advanced multipath", documents > > may optionally clarify that they are not using the term "advanced > > multipath" as defined by this document if clarification is deemed > > helpful. > > > > I see no problem with this. Please be more specific if you think > > there are places where advanced multipath is used as an adjective or > > where its use is confusing. > > > > I believe my confusion was not understanding the differences between > "Advanced Multipath" (with words capitalized) and "advanced multipath" > (with words lower cased). While I understand this is your intent, I see > it as just leading to confusion. Ultimately, it's the author's / WG's > call, i.e., not mine, to make. OK so here is a suggestion to improve this. OLD Advanced Multipath Advanced Multipath meets the requirements defined in this document. A key capability of advanced multipath is the support of non-homogeneous component links. OLD NEW Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. NEWER Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. Advanced Multipath Group (AMG) An Advanced Multipath Group (AMG) is group of component links where Advanced Multipath techniques are applied. This along the lines of "Link Aggregation" and LAG. The first is 802.1ax (or whatever, see the references). The latter is a group of component links. Not to be confused with Absorbed Glass Mat lead-acid batteries... (which is AGM not AMG). But if you see me write AGM, you'll know why (habit, typo). I think if we use these definitions and make if this terminology change is made everywhere in the document we will acheive the improved clarity that you were looking for. Is this OK? > >> 2. Editorial: server and client layer vs upper and lower layer. > >> > >> The document uses server and client layer networks and LSPs and, > >> sometimes interchangeably or redundantly, upper and lower layer networks > >> and LSPs. I think this issue can be resolved by avoiding the term > >> client/server when referring to network layers and just using the > >> lower/upper terminology. The one exception to this is in the definition > >> Client LSP which should simply be defined in the context of a multipath, > >> i.e.: > >> OLD > >> A client LSP is an LSP which has been set up over a server layer. > >> NEW > >> A client LSP is an LSP which has been set up over Advanced Multipath. > > > > A client LSP can be set up over a server layer MPLS-TP LSP or any > > server layer MPLS LSP or over a link layer or over a pseudowire ... or > > over an advanced multipath. > > > > Would you accept s/server layer/lower layer/g? The definition of server layer is not the same as the definition of lower layer. See below. > >> I think this also means that usage of the term "Client" is limited to > >> "Client LSP". > > > > I searched for all occurances of the word client. All occurances are > > "client LSP" excexpt the phrase "client of a client LSP" and that is > > used only in the following paragraph. > > > > The ingress and egress of a multipath may be midpoint LSRs with > > respect to a given client LSP. A midpoint LSR does not participate > > in the signaling of any clients of the client LSP. Therefore, in > > general, multipath endpoints cannot determine requirements of clients > > of a client LSP through participation in the signaling of the clients > > of the client LSP. > > > > THe point is that "A midpoint LSR does not participate in the > > signaling of any clients of the client LSP" and that non-participation > > in client (or higher layer) signaling applies to any "client of a > > client LSP", not just other LSP running over it. > > > > I then searched for all occurances of the words upper and lower and > > higher. There are no occurances of "upper". > > > > There were a few occurances of "lower latency" and "higher latency". > > Other than that, all occurances of lower and higher except one are in > > the follwoing text: > > > > 3.2. Component Links Provided by Lower Layer Networks > > > > A component link may be supported by a lower layer network. For > > example, the lower layer may be a circuit switched network or another > > MPLS network (e.g., MPLS-TP)). The lower layer network may change > > the latency (and/or other performance parameters) seen by the client > > layer. Currently, there is no protocol for the lower layer network > > to inform the higher layer network of a change in a performance > > parameter. Communication of the latency performance parameter is a > > very important requirement. Communication of other performance > > parameters (e.g., delay variation) is desirable. > > > > FR#8 The solution SHALL specify a protocol means to allow a lower > > layer server network to communicate latency to the higher layer > > client network. > > > > The exception is this sentence: > > > > FR#22 The solution SHOULD support the use case where an advanced > > multipath itself is a component link for a higher order advanced > > multipath. For example, an advanced multipath comprised of MPLS- > > TP bi-directional tunnels viewed as logical links could then be > > used as a component link in yet another advanced multipath that > > connects MPLS routers. > > > > The terms lower layer and higher layer go all the way back to the ISO > > seven layer model of ancient times (1970s?, 1980s?) and maybe further > > back but that is before even my time. > > > > I don't think this is unclear but I could add the following in > > definitions: > > > > Higher Layers > > A client layer is the one immediately above a server layer. The > > client layer and all layers above that layer are higher layers. > > > > Lower Layers > > A server layer is the later immediately below a client laer. > > The server layer and all layers below are lower layers. > > > > Do I really need to put this in the definitions section? If yoy think > > it is necessary, I will add it. > > > Perhaps we've talked (okay written) past each other. I was suggesting > using/keeping the "higher and lower layer" terminology, not dropping it. > And to use it (consistently) in place of "client and server Layer". I guess you missed the distinction in the definition above: For layer X layer Y is: client layer === Y = X+1 server layer === Y = X-1 higher layer === Y > X lower layer === Y < X So the definition client layer is not the same as the definition of higher layer. The definition of server layer is not the same as the definition of lower layer. In some discussions we really do mean "the server layer" and not any layer at any arbitrary depth below this one. > >> 3. Technical: The document should make it clear that LSPs can provide > >> paths from an Advanced Multipath. I suggest adding something like the > >> the following at the end of page 3 > >> d. a lower layer LSP. > > > > Case "b." is intended to include LSP but is not specifically limited > > to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, > > Ethernet Link Aggregation, and all sorts of things that don't involve > > MPLS at all. For example, a path in Ethernet Link Aggregation Group > > (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though > > this would be unknown to the LAG, or in the simplest case each path in > > the set of LAG members could be supported by a plain Ethernet cable. > > > > okay, how about: > OLD > b. may be specific paths across a network to a destination > node, or > NEW > b. specific paths across a network to a destination > node (e.g., via an LSP), or OK. But I like to spell out "for example" and put it after the definition. That would give us: 4. The paths may be: a. parallel links between two nodes, or b. may be specific paths across a network to a destination node, or c. may be links or paths to an intermediate node used to reach a common destination. The paths need not have equal capacity. The paths may or may not have equal cost in a routing protocol. + Paths across a network which serve as a component link in a AMG + may be provided by other LSP acting as server LSP for the + client AMG. Component links of a given AMG need not all use the + same type of server layer technology. For example, one may be a + physical Ethernet, another a Packet Over Sonet (POS) link, + another a pseudowire, and another an LSP with individual hops + using a mix of lower layer technologies. Is that an acceptable clarification? btw - in b. and c. s/may be// since "may be" precedes the list. > >> and at the end of the Component Link definition: > >> A component link may be provided via an LSP. > > > > I think this is covered in "3.2. Component Links Provided by Lower > > Layer Networks". > > > > 3.2. Component Links Provided by Lower Layer Networks > > > > A component link may be supported by a lower layer network. For > > example, the lower layer may be a circuit switched network or another > > MPLS network (e.g., MPLS-TP)). > > > > This sort of statement could be made earlier. For example in the > > discussion following the definitions (on page 5) the document covers > > one case (where a component link is not an LSP) but it is not until > > later that the other case is mentioned. > > > > I could add a paragraph in the discussion following the definitions > > that mentions that a component link can also be another LSP. > > > > OLD: > > > > A Component Link may be a point-to-point physical link (where a > > "physical link" includes one or more link layer plus a physical > > 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 Performance Objectives. For > > example, a component link may be comprised of any supportable > > combination of link layers over a physical layer or over logical sub- > > layers, including those providing physical layer emulation. > > > > NEW: > > > > A Component Link may be a point-to-point physical link (where a > > "physical link" includes one or more link layer plus a physical > > 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 Performance Objectives. For > > example, a component link may be comprised of any supportable > > combination of link layers over a physical layer or over logical sub- > > layers, including those providing physical layer emulation, or over > > MPLS server layer LSP. > > > > These are identical except the phrase ", or over MPLS server layer > > LSP" added to the end of the last sentence. > > Sure. > > > > >> 4. Editorial: Unless I'm mistaken, the requirements in this document > >> apply to the Advanced Multipath solution. In most cases the document > >> states requirements in the form of "The solution", but in a few cases it > >> just says "advanced multipath". I think these cases should be changed > >> to apply to an "Advanced Multipath solution". I think this comment > >> applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. > > > > That is not correct. For example: > > > > FR#1 An advanced multipath MAY be announced in conjunction with > > detailed parameters about its component links, such as bandwidth > > and latency. The advanced multipath SHALL behave as a single IGP > > adjacency. > > > > In this requirement the "advanced multipath" is a specific collection > > of component links that is announced by way of an MPLS Forwarding > > Adjaccency (FA) in the IGP. The same is true for the other > > requirements cited. In all of these cases an advanced multipath is a > > specific collection of component links. > > Hereto, the distinction between "advanced multipath" and "Advanced > Multipath" was lost on me. OK. "Advanced Multipath" vs AMG might improve clarity. > > There is a typo in MR#1. > > > > OLD > > > > MR#1 Management Plane MUST support polling of the status and > > configuration of an advanced multipath and its individual > > advanced multipath and support notification of status change. > > > > NEW > > > > MR#1 Management Plane MUST support polling of the status and > > configuration of an advanced multipath and its individual > > component links and support notification of status change. > > > > In the last line > > s/advanced multipath/component links/ > > > >> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > >> In these cases it is unclear if the requirements apply to > >> (a) a client's ability to indicate a desired service/LSP constraint or > >> (b) a selected component link's attribute that will be used by a client > >> LSP, > >> (c) both, or > >> (d) something completely different > >> The requirements should be clear to which entity the requirement applies. > > > > This "indication" can be through signaling or the management plane and > > both must be supported in later framework and protocol definitions and > > we can argue then whether both must be supported or if one or the > > other is a "should" in RFC 2119 speak. > > > > There was concern that the word "signal" would exclude providing the > > same informantion through the management plane and therefore the word > > "indicate" is used. > > > > Rather than spell this out many times we hoped this would be clear. I > > could add clarifying text up front if you think this is necessary. For > > example, I could add the following before FR#1. > > > > FR#0 In requirements that follow in this document the word > > "indicate" is used where information may be provided by either > > the combination of link state IGP advertisement and MPLS LSP > > signaling or via management plane protocols. In later documents > > providing framework and protocol definitions both signaling and > > management plane mechanisms MUST be defined. > > > > So is this the IGP/signaling that runs between a client an an AM "LER", > between an AM "LSR" and its server network, or between AM LSRs? If I > understand AM properly, there may be *up to* there separate instances. > Am I missing something? Please don't abbreviate Advanced Multipath as AM. Link Aggregation is not LA. The word "indicate" is independent of the method of getting the information there. But yes in the example given the IGP advertisement and MPLS LSP signaling that might be one such mechanism does refer to the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there is only one IGP flooding information for both client and server layer, hence the seemingly endless (and mostly pointless) discussion of sub-layer vs layer from certain ITU people in the MPLS WG mailing list who viewed MPLS as broken for not enforcing a strict layering in this regard. But we need not go into that level of detail in this example of how independent of mechanism the "indicate" is and down that years old MPLS WG terminology rat hole again. > > It would be trivial to make this FR#1 and renumber the rest. > > > > I don't think the FR helped clarify the above question. The choice of the word "indicate" in FR10-13, FR14, FR15 does not imply usage by a specific layer. That is a direct answer to your question. In all of these specific cases, the the client layer is passing a requirement to the server layer so in the IGP + RSVP-TE world that would be a function of RSVP-TE. In the absense of control plane, it would have to be done through management plane interaction where the client indicates requirements of an LSP and the server layer is free to figure out how to meet those requirements. Do you want me to add the clarification on the use of the word "indicate" or not? > > Should I add it and renumber? > > > >> 6. The last paragraph in section 3.3. strikes me as both odd and out of > >> place. There are so many possible decisions that must be considered by > >> network operators relative to disruption and optimization. Why mention > >> just "power reduction"? Is there something special about the > >> interactions of multipath and power reduction? What value / information > >> does this paragraph add? > > > > The last paragraph in section 3.3 is: > > > > Allowing multipath to contain component links with different > > characteristics can improve the overall load balance and can be > > accomplished while still accommodating the more strict requirements > > of a subset of client LSP. > > > > I'm not sure if this is the "odd and out of place" paragraph you refer > > to. It summarizes the purpose of the requirements in this section. I > > think you mean section 3.5 and not 3.3. > > > > Correct. > > > The remainder of your paragraph above discusses power reducetion and > > this is only mentioned in section 3.5 so I think you mean this > > paragraph. > > > Right again. > > > 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 weigh the benefit of power reduction against the disadvantage > > of a minimal disruption. > > > > The paragraphs following a set of requirements provide discussion > > related to that set of requirements. I don't see this as out of > > place. The prior two paragraphs discuss delay discontinuity. This > > paragraph is a reminder that "As with any load balancing change, a > > change initiated for the purpose of power reduction may be minimally > > disruptive." I don't see this as out of place. > > > > For example, to compensate for a less than perfect load balance a > > subset of LSPs may need to be moved and that subset can be chosen from > > those which will be least affected (and there are plenty of > > requirements that compell the fussy LSP to tell the network abour > > their specifial needs). To power down a component link, *all* LSP on > > that component link need to be moved, even the very fussy ones. > > Therefore I think mentioning that disruption should be considered is > > not out of place in the discussion following these requirements. We > > like to keep the discussion brief so this level of detail was not > > included. > > > > I guess we see the importance of this topic differently. So will this > be the first RFC that uses the term "power reduction"? Perhaps. A co-author originally wanted it added. The set of authors kicked this around and reworded the original. The wording is brief and vague and the use of MAY in the actual requirement means we will not disallow this. So far no one in the WG has objected to this wording and its been there a long time. Would you like me to remove the requirement and discussion of its implications after the WG concensus so far was to keep it? > >> 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean > >> AS? > > > > At the very least it means something similar to same administrative > > domain. An AS can be subdivided within an organization. Do you have > > a better way to define intra-domain and inter-domain without going > > down the rat hole of defining the term "domain"? > > I'd use something like "multiple ASes or routing domains". If you > really want to avoid domains you could say areas or levels. OK. s/MPLS network topology/routing domain/ > > No on in the WG had > > an issue with this so far but I'm open for a suggestion for better > > wording. > > You're forgetting my "real" name;-) You plan on living up to it I see. :-) > >> Nits: > >> > >> - References should be provided in all cases when referring to > >> "existing ... techniques" > > > > References are not allowed in the abstract. In section 3.3 is the sentence: > > > > Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a > > description of existing techniques and a set of references. > > > > Much of that document is dedicated to describing existing techniques > > and it contains quite a few references. > > > > I can move this sentence. Where in the document would you like to see > > it moved to? > > > (Lines numbers from URL below.) > Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. > > >> Using line numbers from > >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt > > > > Using line number is a text editor counts the page headers. What tool > > are you using? I didn't see anything on tools.ietf.org. > > > huh. enter the above URL in a browser and you should see the line numbers. > > > So I'll guess. Looks like add 10 lines per page. > > > > >> Line 112 > >> s/SHOULD/should > > > > s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ > > > > Also remove stray comma. > > > I don't think use of 2119 language being applied to the reader is > appropriate, but whatever... You want me to downcase "SHOULD be interpreted". I missed a M-l in the s/// edit (emacs downcase next word) and got only the stray comma. > >> Line 118 > >> s/MAY/may > > > > s/deployment MAY choose to/deployment may choose to/ > > > > OK. Could go either way but s/MAY chose to/MAY/ would work too. > > > No. The issue is that this document doesn't place conformance > requirements on a service provider so RFC2119 language isn't appropriate > here. No IETF document truly places conformance requirements on either the service provider or implementor, but we put RFC2119 language in telling them what to do all the time. No one in IETF signed a legal document forcing them to adhere to every RFC2119 keyword in each document. The requirements here are 1) implementor SHOULD provide a per feature knob to turn individual features off, 2) provider MAY use those knobs, including knobs that another implementor made available. This is just trying to avoid unnecessarily inflexible specifications or unnecessarily inflexible implementations where some feature doesn't work when an unrelated feature is disabled. This is in here because this inflexibility happens. The framework can outline any feature dependencies. > >> Line 149, match intro: > >> s/Advanced Multipath meets/Advanced Multipath is a formalization of > >> multipath techniques that meet > > > > OK. > > > >> Lines 251-254, beginning with "The" through the end of the paragraph. > >> This should be an FR. > > > > Looks like you mean this: > > > > The transient period between some service disrupting > > event and the convergence of the routing and/or signaling protocols > > MUST occur within a time frame specified by Performance Objective > > values. > > > Right. > > OK. I'll add this as FR#6++. > > > > >> That's it, > >> Lou > > > > There are a few suggestions for changes to the text based on your > > comments and a few questions for you. Based on your response to this > > email I will edit the document. > > > > Thanks for the thorough review. > > > > Thanks for the responses and the resend! > > Lou Sorry to mess up my own DNS and require a resend and a delay. Curtis > > Curtis > > > > - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- > > > > > > ------- End of Forwarded Message _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
