Re: (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13

[Lou Berger <[e-mail]>]

sounds like a plan!

Lou

On 01/17/2014 12:41 PM, Curtis Villamizar wrote:
> In message <[e-mail]>
> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>>> 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
>