Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13
Lou Berger <lberger@labn.net> Tue, 28 January 2014 23:06 UTC
Return-Path: <lberger@labn.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2716C1A03E7 for <rtg-dir@ietfa.amsl.com>; Tue, 28 Jan 2014 15:06:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg6GGHx2hg50 for <rtg-dir@ietfa.amsl.com>; Tue, 28 Jan 2014 15:06:24 -0800 (PST)
Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id 40DFA1A033C for <rtg-dir@ietf.org>; Tue, 28 Jan 2014 15:06:24 -0800 (PST)
Received: (qmail 2888 invoked by uid 0); 28 Jan 2014 23:06:21 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 28 Jan 2014 23:06:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6QmzKPN4Y81s4kamU7ZtJNJ7UVPuOo3busMaAm9Yocw=; b=P4DEs8/g76V8vWOQ6LrqMWYxolhO2iCaWRsqZ8/Qy3mgEMkZ7MViW9LwvSWDq84OEv5GgnEpSen6Rogf+61+b/whwBwOVCrra73P1Wml3WW6zbVedUXFPFH0UmZv3Zjo;
Received: from box313.bluehost.com ([69.89.31.113]:59650 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1W8HjZ-0008Rn-AT; Tue, 28 Jan 2014 16:06:21 -0700
Message-ID: <52E837E8.3000001@labn.net>
Date: Tue, 28 Jan 2014 18:06:16 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: curtis@ipv6.occnc.com
References: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com>
In-Reply-To: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>, rtgwg@ietf.org
Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 23:06:29 -0000
Curtis, The changes in the current rev address most of my comments and the document is significantly less ambiguous. I'm still not a big fan of how client and layers are used in the document, but I think this is in the weeds and we should move on and not engage, as the draft says, "in long and pointless discussions". Lou On 1/25/2014 2:20 PM, Curtis Villamizar wrote: > Lou, > > I am in the process of submitting a -14 version followed with only the > changes for the OpsDir review followed by a -15 version with the > additional changes from your RtgDir review. Please wait for the -15 > version if you see the -14 and not the -15. > > Curtis > > > In message <52D96FFD.1020408@labn.net> > Lou Berger writes: >> >> sounds like a plan! >> >> Lou >> >> On 01/17/2014 12:41 PM, Curtis Villamizar wrote: >>> In message <52D88F77.5020009@labn.net> >>> Lou Berger writes: >>> >>>> Curtis, >>>> I'm not sure if we're going around in circles or not, but in either >>>> case case I think we're getting caught up in the weeds/details. >>>> >>>> >From a high level perspective, my comments have been motivated by trying >>>> to ensure the requirements are unambiguous -- as documented. I think >>>> the text changes that have been agreed to so far (notably the use of the >>>> capitalized term and introduction of AMG) will help a lot. I think there >>>> is still one more area that is unclear, but it's also possible that >>>> we're arguing about text that you are planning to change. >>>> >>>> Do you have a version that captures all the changes to date that you can >>>> distribute (or submit, as you choose)? Perhaps looking at this version >>>> we'll find that the ambiguity is resolved or is sufficiently narrowed to >>>> not be significant. Either way, the discussion can then continue from >>>> the most current text. >>>> >>>> Thanks, >>>> Lou >>> >>> >>> Lou, >>> >>> I was going to suggest the same (if I understand your suggestion) - >>> that is that a new draft be submitted and you (and others) can review >>> and see if clarity has been sufficiently improved or if there are >>> still issues with clarity. >>> >>> If that is OK with you and compatible with this process I will make >>> two draft submissions back to back. One with just the OpsDir review >>> comments addressed and a second with your comments so far addressed. >>> IMHO it would be easier to discuss the clarity (or lack of) of the >>> wording once changes have been made particularly since there are a few >>> s/old/new/g terminology suggestions in the email thread. >>> >>> Curtis >>> >>> >>>> On 1/15/2014 7:00 PM, Curtis Villamizar wrote: >>>>> In message <52D02F67.9070604@labn.net> >>>>> Lou Berger writes: >>>>> >>>>>> Curtis, >>>>>> >>>>>> I think we have one disconnect (and corresponding related text) that we >>>>>> need to resolve before we can be close the discussion. See below for >>>>>> details.. >>>>>> >>>>>> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: >>>>>>> Converging. But maybe one more round trip needed. >>>>>>> >>>>>>> In message <52CD9D58.4010109@labn.net> >>>>>>> Lou Berger writes: >>>>>>>> >>>>>> ... >>>>>> >>>>>>>>>>>> 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.) >>>>>>> >>>>>>> FR#8 and FR#9 are about the server layer telling the client layer >>>>>>> about the delays that can be expected. There is a little redundancy >>>>>>> here so s/ower layer server network/server network/ and >>>>>>> s/higher layer client network/client network/. No plans to skip >>>>>>> layers. >>>>>>> >>>>>> >>>>>> I think we need to hit the points below before this one... >>>>> >>>>> OK. >>>>> >>>>>>>> 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. >>>>>>> >>>>>>> Nope. In general, a client LSP can be set up over a plain old >>>>>>> Ethernet on a given hop, therefore the second definition is too >>>>>>> narrow with this change. >>>>>>> >>>>>> >>>>>> humm, you didn't have that in your OLD text. In fact, the old text >>>>>> reads to me that an Advanced Multipath (solution?) logically sits >>>>>> between a client LSP and an underlying server layer in all cases. >>>>> >>>>> The "OLD" was a quote from you and it was the original text in -13. I >>>>> said "Nope. ..." to your suggested change to it in this way. >>>>> >>>>> Earlier >>>>> (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I >>>>> had suggested the following change: >>>>> >>>>> 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. >>>>> >>>>> You will find this in the quoted text above. >>>>> >>>>> The definition of client LSP does not imply that Advanced Multipath is >>>>> a layer. This also used lower case "multipath" which we can replace >>>>> with AMG. There is no LAG layer in a network in with MPLS runs over >>>>> Ethernet and some of the Ethernets use Link Aggregation. >>>>> >>>>>> So the model I see defined by the text has the following layers >>>>>> >>>>>> Client LSP (layer) >>>>>> ---------- >>>>>> Advanced Multipath (layer/solution/construct) >>>>>> ---------- >>>>>> Server Layer (composed of AMGs which are LSPs and/or links) >>>>>> >>>>>> Is this aligned with your intent? If not, can you explain the >>>>>> relationship you see for Advanced Multipath Client LSPs and Advanced >>>>>> Multipath AMGs? >>>>> >>>>> You imaginged this model and are trying to constrain the text to fit >>>>> into it.. >>>>> >>>>> Consider these examples of client layer and server layer. >>>>> >>>>> plain old rfc-4206 >>>>> >>>>> LSP-1 (PSC-0) = client of LSP-2 >>>>> LSP-2 (PSC-1) = server of LSP-1 >>>>> >>>>> LSP over Ethernet over PW over MPLS >>>>> >>>>> LSP-1 = client of Ethernet >>>>> Ethernet = server of LSP-1, client of PW >>>>> PW = server of Ethernet, client of LSP-2 >>>>> LSP-2 = server of PW >>>>> >>>>> There is then the question of whether Advanced Multipath is a layer or >>>>> a set of techniques that can be applied at a given layer. Example >>>>> potential config language: >>>>> >>>>> mple { >>>>> tunnel x1 { >>>>> type multipath { >>>>> component tunnel x2; >>>>> component tunnel x3; >>>>> [...] >>>>> component intf i1; >>>>> component intf i2; >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> No distinct layer above. >>>>> >>>>> An alternate: >>>>> >>>>> mple { >>>>> tunnel x1 { >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> interface amg1; >>>>> type multipath { >>>>> component tunnel x2; >>>>> component tunnel x3; >>>>> [...] >>>>> component intf i1; >>>>> component intf i2; >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> In the former example, the tunnel x1 is forced to use a specific set >>>>> of component links and apply multipath techniques to it. >>>>> >>>>> In the latter example, if tunnel x1 happen to find that interface amg1 >>>>> was the lowest cost or otherwise preferred way to get to its >>>>> destination it makes use of amg1 and if so inherits the use of the >>>>> multipath techniques. >>>>> >>>>> There is no distinct multipath encapsulation at the date layer so some >>>>> might argue that even in the second case there is no distinct layer, >>>>> just a configuration convenience. >>>>> >>>>> Claiming that Advanced Multipath is of itself a layer may get us into >>>>> a bigger can of worms. >>>>> >>>>> For example in today's ECMP, the next hop consists of multiple >>>>> interfaces. ECMP is not considered a layer between IP and those >>>>> interfaces. Link bundle is also not considered a layer. >>>>> >>>>> In the document we have not claimed that Advanced Multipath is a type >>>>> of layer and we have not claimed that Advanced Multipath is not a type >>>>> of layer. Either way we would get someone arguing that the opposite >>>>> was true. [Some individuals it seems would pick the opposite of >>>>> whatever we picked just because they like to argue about layering.] >>>>> >>>>> Need I remind you of the painfully long and mostly pointless arguments >>>>> in MPLS during the early MPLS-TP work about whether an MPLS LSP >>>>> carried within another hierarchical MPLS LSP was a layer or a >>>>> sub-layer. We don't want to repeat that and the best way to do so is >>>>> to not make any statement about whether Advanced Multipath is a layer >>>>> or a sub-layer or a layering NOOP. >>>>> >>>>> Which of the above is the "right" way to do things may be at most a >>>>> framework issue but may not come up until management plane entities >>>>> are defined. It is certainly not a topic for a requirements document >>>>> because it is deep into the "how it gets done". >>>>> >>>>>>>> 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. >>>>>>> >>>>>>> What about PW? Those are paths too by the definition of paths, so >>>>>>> again, this change makes the definition too narrow. >>>>>>> >>>>>> >>>>>> PWs weren't mentioned in your OLD text, so I didn't add them. I also >>>>>> have no objections to adding them. >>>>> >>>>> Actually the text you wrote is incorrect. "The above requirement >>>>> applies to component links" can include physical links and server >>>>> layer LSP but adding that are part of an Advanced Multipath Group is >>>>> incorrect. >>>>> >>>>> I'm not sure but I think this instance of "server layer" was added to >>>>> that LSP wording because you were confused on last review about client >>>>> LSP vs LSP over which Advanced Multipath was applied so I went around >>>>> changing everything to "client LSP" or "server layer LSP" to make it >>>>> more clear to you. You now seem to be stuck on the wording that is >>>>> essentially saying "any type of component link" including "server >>>>> layer LSP". >>>>> >>>>>> The only change I made was >>>>>> s/sets of paths across a network provided by server layer LSP./ >>>>>> LSPs that are part of an Advanced Multipath Group. >>>>> >>>>> And that change was wrong. A more correct change would be >>>>> >>>>> s/provided by server layer LSP/including paths provided by server >>>>> layer LSP/ >>>>> >>>>> That would include any sort of path across the network. PW could be >>>>> considered an emulated physcial link or another usable type of path >>>>> across the network. >>>>> >>>>> The "above set of requirements" in this case have to do with passing >>>>> down requirements for min latency, bounded latency, and bounded >>>>> jitter. The original paragraph is: >>>>> >>>>> 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. >>>>> >>>>> The intent is "The above set of requirements apply to component links" >>>>> followed by "regardless of what type of component links they are" >>>>> where we had disccssed two types being an interface or emulated >>>>> interface (or virtual interface in some major vendor terms) or an LSP >>>>> (which is also a virtual interface in some major vendor terms). >>>>> >>>>> I don't understand how you can get so hung up on the wording of what >>>>> is intended to convey "regardless of what type of component links they >>>>> are". This has always been clear to the WG. >>>>> >>>>>>>>> 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? >>>>>>> >>>>>>> In each of the requirements you cited it is very clear that the client >>>>>>> later is communicating a requirement to the server layer, but if you'd >>>>>>> like I can reword to make that even more clear by rewording of the >>>>>>> form "SHALL provide a means for the client layer to indicate the >>>>>>> requirements of a client LSP [regarding X]", where X is minimize >>>>>>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific >>>>>>> component link (FR#13), bidirection co-routed (FR#14), no reordering >>>>>>> (FR#15), bounded frequency of rebalance (FR#20). >>>>>> >>>>>> Okay, I think this will/may help. My comment goes back to the model I >>>>>> was asking about above. And to which part of the puzzle the requirement >>>>>> applies. >>>>> >>>>> In some of the above requirements client layer communicated to the >>>>> server layer, whatever the server layer is. Means of communication >>>>> presumed to be RSVP-TE but we can't say that until the framework and >>>>> same capability needs to be available to management plane. >>>>> >>>>> In some of the above requirements server layer communicates to the >>>>> client layer. Means of communication is presumed to be IGP >>>>> extensions, again with same capability available to management plane. >>>>> >>>>> There is no distinct Advanced Multipath layer in control plane or data >>>>> plane. And if there was a distinct control plane layer it would be >>>>> defined in a framework, not a requirements document. >>>>> >>>>>>>>>>> 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. >>>>>>> >>>>>>> There are no distinct three layers. You are imagining a model that is >>>>>>> not used in this document so please don't impose model on our document. >>>>>>> >>>>>> >>>>>> Well your old definition of Client LSP said that it was a client of >>>>>> "multipath" and else where you say that "multipath" operates over a >>>>>> server layer. As mentioned above, this sounds like three layers to me. >>>>>> If this is not your intent, I think you need to make it clear (through >>>>>> revised text) what model you do intend. >>>>> >>>>> This is the current text in -13: >>>>> >>>>> 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. >>>>> >>>>> The text is trying to clarify what a "client LSP" is in the first >>>>> sentence and then trying to give two cases of what a client LSP is >>>>> not. This clarification was specifically added *for you* in the last >>>>> iteration. >>>>> >>>>> There was no intention to imply that Advanced Multipath is or is not >>>>> in of itself a type of layer. If you are getting that notion from >>>>> this text, then we need to change it. >>>>> >>>>> 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 an LSP which has been set up over a set of one >>>>> or more lower layers. In the context of this discussion, one >>>>> type of client LSP is a LSP which has been set up over an AMG. >>>>> >>>>> We could also add a clarification to the definitions section that >>>>> states: >>>>> >>>>> This document makes no statement on whether Advanced Multipath is >>>>> itself a layer or whether an instance of AMG is itself a layer. >>>>> This is to avoid engaging in long and pointless discussions about >>>>> what consistitutes a proper layer. >>>>> >>>>> I would *really* like to add the above statement. >>>>> >>>>>>> In your sentence above I have no idea what "the requirement" refers to. >>>>>>> >>>>>>> In summary: >>>>>>> >>>>>>> We were discussing why the word "indicate" was used to avoid requiring >>>>>>> specific mechanisms for information passing and I asked if I should >>>>>>> add the following. >>>>>>> >>>>>>> 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. >>>>>>> >>>>>>> Information is two way. The requirements you cited were all worded in >>>>>>> the form "The solution SHALL provide a means to indicate that a client >>>>>>> LSP will ...". So far I have offerred to reword this to the form "The >>>>>>> solution SHALL provide a means for the client layer to indicate a >>>>>>> requirement that a client LSP will ..." (ie: get minimum latency, get >>>>>>> bound latency, etc). >>>>>>> >>>>>>> Is adding FR#0 OK? >>>>>>> >>>>>>> Do you want this sort of rewording to make it more explicit that the >>>>>>> client layer is communication a requirement for a specific client LSP? >>>>>>> >>>>>> >>>>>> I think we need to come back to this once we resolve the "model" topic. >>>>>> >>>>>> ... >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>> >>>>> I hope it is resolved. >>>>> >>>>> Curtis > > > > >
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Lou Berger
- [RTG-DIR] RtgDir review: draft-ietf-rtgwg-cl-requ… Lou Berger
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Curtis Villamizar
- Re: [RTG-DIR] RtgDir review: draft-ietf-rtgwg-cl-… Curtis Villamizar
- [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-… Curtis Villamizar
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Lou Berger
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Curtis Villamizar
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Lou Berger
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Curtis Villamizar
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Lou Berger
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Curtis Villamizar
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Lou Berger
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Curtis Villamizar
- Re: [RTG-DIR] (resend) Re: RtgDir review: draft-i… Lou Berger