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 <[email protected]> > 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... >> 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. 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? >> 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. 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. ... > >>> 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. > >>>>> 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. > 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
