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

[Curtis Villamizar <[e-mail]>]

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 <[e-mail]>
Lou Berger writes:
> 
> 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