Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13
Curtis Villamizar <curtis@ipv6.occnc.com> Sat, 25 January 2014 19:21 UTC
Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD691A003B; Sat, 25 Jan 2014 11:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level:
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, 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 3pUtgReEbgMn; Sat, 25 Jan 2014 11:20:58 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2E1A002F; Sat, 25 Jan 2014 11:20:58 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PJKtA4047788; Sat, 25 Jan 2014 14:20:56 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com>
To: Lou Berger <lberger@labn.net>
From: Curtis Villamizar <curtis@ipv6.occnc.com>
Subject: Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13
In-reply-to: Your message of "Fri, 17 Jan 2014 13:01:33 -0500." <52D96FFD.1020408@labn.net>
Date: Sat, 25 Jan 2014 14:20:55 -0500
Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jan 2014 19:21:03 -0000
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
- RtgDir review: draft-ietf-rtgwg-cl-requirement-13 Lou Berger
- Re: RtgDir review: draft-ietf-rtgwg-cl-requiremen… Curtis Villamizar
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Curtis Villamizar
- (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-r… Curtis Villamizar
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Lou Berger
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Curtis Villamizar
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Lou Berger
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Curtis Villamizar
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Lou Berger
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Lou Berger
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Curtis Villamizar
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Lou Berger
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Curtis Villamizar
- Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-… Lou Berger