Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13

[Lou Berger <[e-mail]>]

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

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
> 
> 
> 
>