Hi Curtis, See below.
On 01/07/2014 09:56 PM, Curtis Villamizar wrote: > 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. > Right, you're the author.... >> 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 > no problem at all on this one, so I think you're up and working! > >>> In message <[email protected]> >>> Lou Berger writes: >>>> ... >> 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. > Ahh. I think this is much better/clearer! > 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? Yes! > >>>> 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. > I read your usage of client/server layer to be synonymous with higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense of FR#8 (I think you really mean client layer not lower layer.) Given the current document usage, I still think it makes sense to eliminate the two instances of "client layer": How about the following: OLD Client LSP A client LSP is an LSP which has been set up over a server layer. In the context of this discussion, a client LSP is a LSP which has been set up over a multipath as opposed to an LSP representing the multipath itself or any LSP supporting a component links of that multipath. NEW Client LSP A client LSP is a LSP which has been set up over Advanced Multipath as opposed to an LSP representing the Advanced Multipath itself or any LSP that is part of an Advanced Multipath Group. and OLD The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by sets of paths across a network provided by server layer LSP. NEW The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by LSPs that are part of an Advanced Multipath Group. >>>> 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? Given the the definition of AMG I no longer see a need for the change or proposed text (and would prefer not having to discuss the proposed text.) ... >>>> 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. Perhaps you should a requirement on this ;-) > > 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. > My comment is that you need to be clear to which layer a requirement applies. Is it the server layer, the client layer or the Advanced Multipath layer? >>> 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? I think you need to be clear that the requirement applies to all three layers. > >>> 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? > I think the text opens the door to the objection/question as to why just this "application" and not others are called out. Now that I've asked the question, we can move on. The AD can always revisit if he so chooses. ... >>>> 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. > Right. >>>> 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. I'd prefer the first to be a MUST, but you've documented wg consensus. I don't think #2 makes any sense, but we can move on. > > 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. > NP! Lou > Curtis > >>> Curtis >>> >>> - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- >>> >>> >>> ------- End of Forwarded Message > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
