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 <[email protected]>
> Lou Berger writes:
>>
>> sounds like a plan!
>>
>> Lou
>>
>> On 01/17/2014 12:41 PM, Curtis Villamizar wrote:
>>> In message <[email protected]>
>>> 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 <[email protected]>
>>>>> 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 <[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...
>>>>>
>>>>> 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
>
>
>
>
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
