Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

["Igor Bryskin" <ibryskin@movaz.com>]

Dimitri,

Looks like we are talking different languages.

The discussion was inititiated by your question: is it worth advertisng
stitching segments as FAs. At the same time you keep complaining that I
bring PCE into the discussion. Who in your opinion is the user of such
advertising apart from PCE?

I am saying that segments provisioned by the management plane could be used
in e2e LSP dynamic provisioning and the only way to make it possible is via
stitching. You are saying that this is not stitching because in your opinion
stitching is concerned only with segments dynamically provisioned, and there
is some other mechanism (which you were not specific about) that makes
possible using the statically provisioned segments.

Finally:

> > IB>> Just to be clear. You mentioned the use of advertised node
> > capabilities. My point is that these advertisements are useful for path
> > computation but are of no use for e2e signaling
>
> and so just to be clear if they are not useful for e2e signaling what is
> the purpose of advertising them for this purpose ?
>

Comments like these just knock me off. I always believe that any type of
advertising is being done for the purpose of routing and path computation
but have zero relevance for signaling. Am I not right ? Consider, for
instance, the case when all EROs are fully specified by the user. Can I
signal such LSP? If yes, do I need TED in this case?

Igor


----- Original Message ----- 
From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
To: "Igor Bryskin" <ibryskin@movaz.com>
Cc: <dimitri.papadimitriou@alcatel.be>; "Arthi Ayyangar"
<arthi@juniper.net>; <ccamp@ops.ietf.org>
Sent: Thursday, February 17, 2005 5:33 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt


> igor - see in-line:
>
> [snip]
>
> >>>Your point/question is very simple, which is what does it give to
> >>>advertise stitching segments as FAs, is that correct?
> >>>
> >>>My answers are very simple either:
> >>>
> >>>1) How else are you going to use statically provisioned segments as
part
> >>> of dynamically provisioned end-to-end LSPs ?
> >>
> >>you ask a different question from the initial issue because advertize a
> >>TE link was possible today without using stitching, however this issue
> >>also depends what do you mean by statical provisioning ?
> >
> > IB>> I have segments that are provisioned/owned by the management plane
>
> exactly - there is no *LSP stitching* anymore - we discuss about control
> plane operations (the intermediate segment is an entity owned by the
> control plane)
>
> note: by the way, operation you are referring to is supported today
> (without the procedures described as part of this document because this
> has nothing to do with stitching)
>
> >>>2) How else you can accomplish a transition strategy when some of the
> >>> nodes that are going to be involved in end-to-end dynamically
provisioned LSPs
> >>> do not have proper signaling software?
> >>
> >>and i did ask what is the point in applying LSP segment signaling on
> >>segment that "do not have proper signaling software"
> >
> > IB>> The point is that transit nodes of the segments do not participate
and
> > hence do not have to support e2e signaling
>
> well i think we should then determine the working assumptions here,
> intermediate nodes part of an LSP segment are GMPLS nodes as any other,
> otherwise the segment could itself not be setup (stitching is just a way
> to leave control to the head-end of the segment but there are no
> specific assumptions made in terms of signaling capabilities for the
> intermediate nodes, they are assumed to be GMPLS signaling capable nodes
> as any other)
>
> >>>The specific example is using LSRs that
> >>>do not support p2mp signaling as transit nodes in p2mp LSPs. Your point
> >>>about advertising of node capabilities is relevant only for routing -
> >>>the PCE computing p2mp tree may take in consideration the advertised
node
> >>>capabilities and assume that stitching segments may be created
> >>>dynamically if needed.
> >>
> >>just to be clear the PCE discussion is completely outside of the present
> >>discussion - afaik the working group has (still) to provide requirements
> >>for the PCE wg -
> >
> > IB>> Just to be clear. You mentioned the use of advertised node
> > capabilities. My point is that these advertisements are useful for path
> > computation but are of no use for e2e signaling
>
> and so just to be clear if they are not useful for e2e signaling what is
> the purpose of advertising them for this purpose ?
>
> >>>What if I don't want them to be dynamically created and rather
> >>>have them pre-provisioned to spead up the process of p2mp tunnel setup
> >>>and decrease blocking probability?
> >>
> >>not sure that compared to the global complexity of computing the tree
> >>this is going to be a significant improvement, but if you have the
> >>possibility to determine the bandwidth on the corr. segments i don't see
> >>here how you decrease the blocking probability (afaik propagation of
> >>segment related information is equivalent to the corresponding links
> >>advertisement)
> >
> > IB>> Dynamic establishment of the stitching segments may fail
>
> not sure to catch your point, if you think a p2p LSP establishment may
> fail not sure it is wise to start thinking about p2mp LSP establishment
> - on the other side pre-provisioning of the segment if not guaranteed
> within certain limits can not guarantee that you would be able to stitch
> it afterwards (refresh, etc.)
>
> >>>3) What if I want to attract certain LSPs  to use pre-provisioned
> >>> segments even if the overall cost of such LSPs would be higher than if
they would
> >>>take paths computed without consideration of these segments, but it is
> >>>desirable for the LSPs to use the segments anyway. Exanple: the
segments
> >>>are provisioned to satisfy wavelength continuity constraint and I don't
have
> >>>PCE that can perform path computation with such contraint on path
segments
> >>>between points of OEO.
> >>
> >>as said above it would desirable to leave PCE aspects outside of the
> >>picture, but this application is really interesting because on one side
> >>i thought we had the label set to solve this issue (note: that even if a
> >>path is pre-computed explicit label control can be used to provision the
> >>segment between converting points - don't PCEs for this)
> >
> > IB>> First, this is just an example of the situation when I want
> > pre-provisioned segments to be used in e2e LSP provisioning.
> > Second, satisfying the wavelength continuity constraint takes much more
> > than just using the label set. You need to have:
> > a) information about all lambdas in all isles of transparency;
>
> this may be the case but once known explicit label control on each link
> is enough to assume continuity
>
> > b) very complex PCE that is capable of computing optimal path(s) that
use
> > the same wavelength on all links within each OEO-OEO segments satisfying
all
> > other optical constraints.
>
> PCE, again PCE, but the computation of such path was possible well
> before even the term did exist - you mix the computation with the access
> to the computation result -
>
> > It is much simpler to pre-provision such OEO-OEO segments and advertise
them
> > as TE links, than a simple PCE would do the job.
>
> it is the term "pre-provision" that causes the main issue here, one
> dimension of the problem is simplified but how many are getting
> complexified ? and where is the evaluation of this trade-off ?
>
> > Igor
> >
> >
> >>on the other hand is how much possible pre-provisioned segments - so
> >>overhead - are now going to be advertised if the traffic demand is
> >>unknown ? and on the other hand, if all traffic matrix is known
> >>beforehand is there any rationale to create these segments instead of
> >>directly provisioning
> >>
> >>it is interesting to see that you are populating this discussion with
> >>PCE application - i would be more in favor in leaving the possibility of
> >>advertising segments once a clear set is being identified rather than
> >>the other way around
> >>
> >>
> >>>Igor
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>----- Original Message ----- 
> >>>From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
> >>>To: "Igor Bryskin" <ibryskin@movaz.com>
> >>>Cc: <dimitri.papadimitriou@alcatel.be>; "Arthi Ayyangar"
> >>><arthi@juniper.net>; <ccamp@ops.ietf.org>
> >>>Sent: Thursday, February 17, 2005 1:19 PM
> >>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >>>
> >>>
> >>>
> >>>
> >>>>Igor Bryskin wrote:
> >>>>
> >>>>
> >>>>
> >>>>>dimitri, see in line.
> >>>>>
> >>>>>----- Original Message ----- 
> >>>>>From: "dimitri papadimitriou" <dpapadimitriou@psg.com>
> >>>>>To: "Igor Bryskin" <ibryskin@movaz.com>
> >>>>>Cc: <dimitri.papadimitriou@alcatel.be>; "Arthi Ayyangar"
> >>>>><arthi@juniper.net>; <ccamp@ops.ietf.org>
> >>>>>Sent: Thursday, February 17, 2005 11:40 AM
> >>>>>Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>igor - see in-line
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>>>Please see my replies (AA--->) inline.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>---------> An LSP segment may be created either by
configuration
> >>>
> >>>or
> >>>
> >>>
> >>>>>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to
an
> >>>
> >>>FA,
> >>>
> >>>
> >>>>>an
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>>LSP segment may or may not be advertised as a TE link. But, if
> >>>>>>>>>>>>pre-created, it could be advertised, in which case other nodes
> >
> > may
> >
> >>>>>>>>>>>>compute a path over it.
> >>>>>>>>>>>>
> >>>>>>>>>>>>Why would you want to or not want to advertise an FA ?
> >>>>>>>>>>>
> >>>>>>>>>>>i understand the point on pre-created <-> advertised but this
> >>>>>
> >>>>>knowledge
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>may be useful for nodes part of the same area (not for nodes
> >>>
> >>>external
> >>>
> >>>
> >>>>>>>>>>>to this area)
> >>>>>>>>>>
> >>>>>>>>>>AA -------> Absolutely ...this definitely cannot be advertised
> >>>
> >>>outside
> >>>
> >>>
> >>>>>>>>>>the area (domain). I think this has been explicitly mentioned.
> >>>>>>>>>>
> >>>>>>>>>>so in case a node for inst. advertises three terminating
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>links with PSC-2 (one of these being the LSP segment) then a
> >>>
> >>>another
> >>>
> >>>
> >>>>>>>>>>>node (part of the same area) receiving an incoming multi-area
> >
> > PSC-2
> >
> >>>>>LSP
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>request may start making use of this segment to join the next
> >>>
> >>>border,
> >>>
> >>>
> >>>>>>>>>>>therefore advertisement of the LSP segment may create a
multi-hop
> >>>>>>>>>>>condition, but now once used relevance of the existence of the
> >>>>>
> >>>>>segment
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>is not a useful information (for the area) as there is no
> >>>
> >>>possibility
> >>>
> >>>
> >>>>>>>>>>>to make re-use of it except when the end-to-end LSP is torn
down
> >>>>>>>>>>
> >>>>>>>>>>AA----------> I understand your point that once an LSP has been
> >>>>>
> >>>>>admitted
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>into an LSP segment it is no longer usable by other nodes in
that
> >>>>>
> >>>>>area.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>But would you rather stop advertising the link at this point, if
> >
> > you
> >
> >>>>>>>>>>were previously advertising it ? Don't you think that is a big
> >>>
> >>>hammer
> >>>
> >>>
> >>>>>? E.g.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>how would a head end which has indeed computed a path over that
> >
> > LSP
> >
> >>>>>>>>>>segment differentiate this event from an LSP segment down event
> >>>
> >>>where
> >>>
> >>>
> >>>>>>>>>>the link is deleted from the database ? So, all the document
says
> >>>>>
> >>>>>today is
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>that you set the unreserved bw on the LSP segment to zero. The
> >
> > idea
> >
> >>>is
> >>>
> >>>
> >>>>>>>>>>to still let other nodes know that the link exists but is
> >
> > unusable.
> >
> >>>It
> >>>
> >>>
> >>>>>is
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>not different from a FA-LSP being consumed...in that case we
don't
> >>>>>
> >>>>>stop
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>advertising the FA (if we were doing so previously), right ?
> >>>>>>>>>
> >>>>>>>>>IB>> Completley agree with Arthi. Besides, several parallel
> >
> > stitching
> >
> >>>>>>>>>segments could be advertised as a single bundle - hence, using
the
> >>>>>>>>>advertised link by one LSP does not necessarily take away all
> >
> > link's
> >
> >>>>>>>>>bandwidth.
> >>>>>>>>
> >>>>>>>>you don't understand the question, it is do we have to consider as
> >>>>>>>>default behavior that a pre-provisioned is to be "advertized"
> >>>>>>>
> >>>>>>>IB>> My point was that I do not see any difference in this respect
> >>>>>
> >>>>>between
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in
> >
> > the
> >
> >>>>>lower
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>layer. Besides, what do you mean by the default behaviour? The fact
> >>>>>
> >>>>>whether
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>to advertise//remove FA TE link is a policy driven carefully
thought
> >>>>>
> >>>>>through
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>decision, a dnagerous one that could potentially destabilize the
> >>>>>
> >>>>>network.
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>I'd say that the default behaviour is "NOT ADVERTISE" in either
case.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>now beside the fact that there are techniques to do so what would
be
> >>>
> >>>the
> >>>
> >>>
> >>>>>>>>purpose of it ? and what it the overhead that such advertisement
> >
> > would
> >
> >>>>>>>>create - that can be of course decreased by bundling them -
> >>>>>>>
> >>>>>>>IB>> The purpose is exactly the same as for any other FA-LSP - add
> >>>>>>>flexibility in a particular layer.
> >>>>>>
> >>>>>>which flexibility are we expecting here, this "segment" can
> >
> > accommodate
> >
> >>>>>>exactly one incoming request -
> >>>>>
> >>>>>
> >>>>>IB>> Disagree - the segment could be a component link within a
bundle.
> >>>
> >>>In
> >>>
> >>>
> >>>>>this case stitching FA TE link may accomodate multiple LSPs
> >>>>>
> >>>>>additionally only nodes part of the same
> >>>>>
> >>>>>
> >>>>>
> >>>>>>area can make use of this advertisement -
> >>>>>
> >>>>>
> >>>>>IB>> Who said that sticthing segments must necessarily terminate on
> >>>
> >>>domain
> >>>
> >>>
> >>>>>borders? There could be multiple reasons why a network operator could
> >>>>>pre-provision (dynamically or statically) LSP segments inside his
> >>>
> >>>network
> >>>
> >>>
> >>>>>and advertise them (as bundles or individually) as TE links to be
used
> >>>
> >>>for
> >>>
> >>>
> >>>>>specific TE purposes.
> >>>>
> >>>>it is exactly these purposes that i am looking for
> >>>>
> >>>>
> >>>>
> >>>>>so in fact what it would allow
> >>>>>
> >>>>>
> >>>>>
> >>>>>>is the possibility to avoid creation of a segment if the edge node
> >>>>>>receiving the request re-orients its request to the head-end for
this
> >>>>>>advertisement
> >>>>>>                       |
> >>>>>>example:      ----------D----------
> >>>>>>            |                     |
> >>>>>>          - A ---- Segment 1 ---- B -
> >>>>>>            |                     |
> >>>>>>             ----------C----------
> >>>>>>                       |
> >>>>>>
> >>>>>>you would have a segment between A-B that could be reached from C
(the
> >>>>>>node receiving the incoming request) decides to make use of this
> >
> > segment
> >
> >>>>>>to reach B (so you would have C-A-B) but if this was the best path
> >
> > why
> >
> >>>>>>not creating directly a segment C-A-B, instead of now having one
> >
> > segment
> >
> >>>>>>C-A, the pre-provisioned A-B and probably one on top of it C-A-B ?
> >>>>>
> >>>>>
> >>>>>IB>> See my comment above. I might want to use statically provisioned
> >>>>>segments. I might want to use nodes that do not have proper signaling
> >>>>>software.
> >>>>
> >>>>what does that mean "proper signaling software"
> >>>>
> >>>>
> >>>>
> >>>>>For instance, recall the discussions on P2MP and how we want use
legacy
> >>>
> >>>LSRs
> >>>
> >>>
> >>>>>to be part of P2MP tunnels
> >>>>
> >>>>but in this case there is a flag telling capabilities of the nodes in
> >>>>order to allow for dynamically trigger the segment
> >>>>
> >>>>
> >>>>
> >>>>>>in case of classical FA-LSP it makes sense to advertize the FA link
> >>>>>>because it represents a lower region LSP (with usually a given ratio
> >
> > of
> >
> >>>>>>unreserved bandwidth that makes worth advertizing the FA link) but
in
> >>>>>>case of a segment i do have some difficulties to excatly see where
> >
> > this
> >
> >>>>>>flexibility would deliver ?
> >>>>>
> >>>>>
> >>>>>IB>> Again, if you imagine that several parallel sticthing segments
are
> >>>>>advertised as as single FA, how it would be different from the
> >
> > bandwidth
> >
> >>>>>usage point of view compared to advertising lower layer FA ?
> >>>>
> >>>>issues are different - FAs are used in manner to preferentially
attract
> >>>>over them because - i am still looking for the reason for attracting
> >>>>over a bundle
> >>>>
> >>>>
> >>>>
> >>>>>In fact it would be even more useful, because in case of lower layer
FA
> >>>
> >>>you need also
> >>>
> >>>
> >>>>>to advertise termination/adaptation capabilities, while in case of
> >>>
> >>>stitching
> >>>
> >>>
> >>>>>FA no addaptation is required.
> >>>>
> >>>>by the way you don't seem to see the issue that i am pointing out, so
> >>>>probably there is a need to go in more detailed examples before
drawing
> >>>>the above confusing conclusion
> >>>>
> >>>>
> >>>>
> >>>>>Igor
> >>>>>
> >>>>>
> >>>>>
> >>>>>>thanks,
> >>>>>>- dimitri.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>>thanks,
> >>>>>>>>- dimitri.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>a more technical point is related to the definition of an FA
LSP
> >>>>>
> >>>>>which
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the
> >
> > head-end
> >
> >>>>>and
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>tail-end switching capability represent the SC of the resulting
> >
> > TE
> >
> >>>>>link
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>while intermediate node terminates the SC corr. to the
switching
> >>>
> >>>type
> >>>
> >>>
> >>>>>>>of
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>>the FA-LSP (e.g. creation of a [PSC-1,PSC-1] link throughout a
> >>>
> >>>PSC-2
> >>>
> >>>
> >>>>>>>>>>>capable network with first and last link being [PSC-1,PSC-2]
and
> >>>>>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would
> >
> > have
> >
> >>>>>now
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>>the creation of a [PSC-1,PSC-1] link with first and last link
> >
> > being
> >
> >>>>>>>>>>>[PSC-1,PSC-1] and [PSC-1,PSC-1], resp. so there is no region
> >
> > border
> >
> >>>>>>>>>>>crossing anymore - so here the question is about definition and
> >>>>>>>>>>>detailing the triggers
> >>>>>>>>>>
> >>>>>>>>>>AA--------> As far as trigger for setting up an LSP segment is
> >>>>>>>
> >>>>>>>concerned,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>I agree that there is no longer the notion of "crossing region
> >>>>>>>>>>boundaries". I realize that the document doesn't discuss this,
> >>>>>>>
> >>>>>>>especially
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>given that we are doing other comparisons with FA LSPs. So, I
will
> >>>
> >>>add
> >>>
> >>>
> >>>>>>>>>>this discussion in the next revision. I think in case of LSP
> >
> > segment
> >
> >>>>>the
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>>>>trigger for LSP segment setup would come from a) successful
> >>>
> >>>switching
> >>>
> >>>
> >>>>>>>type
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>and switching capability match and b) some local policy on the
> >
> > node
> >
> >>>>>>>which
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>>dictates the setting up of an LSP segment.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>IB>> I have a comment here. LSP-Hierarchy is not a Bible and
could
> >
> > be
> >
> >>>>>>>>>challenged in many ways. FA LSP is, generally speaking, created
on
> >
> > a
> >
> >>>>>>>layer
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>boundary rather than on region boundary: nothing prevents
creating
> >
> > a
> >
> >>>>>VC4
> >>>>>
> >>>>>
> >>>>>
> >>>>>>>FA
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>LSP that starts and stops in the middle of TDM region to carry
> >>>
> >>>several
> >>>
> >>>
> >>>>>>>VC12
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>LSPs. Furthermore, stitching FA is a special case of FA when it
is
> >>>
> >>>used
> >>>
> >>>
> >>>>>>>by
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>LSPs of the same layer as one where the FA-LSP was created. As
for
> >>>>>>>
> >>>>>>>triggers,
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>there could be multiple ones for setting up/tearing down
stitching
> >>>>>>>
> >>>>>>>FA-LSPs:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>configuration, receiving setup request for inter-domain LSP,
other
> >>>>>>>
> >>>>>>>policies.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>Igor
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>More on a) later.
> >>>>>>>>>>
> >>>>>>>>>>thanks,
> >>>>>>>>>>-arthi
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>.
> >>>>>>>
> >>>>>>
> >>>>>.
> >>>>>
> >>>>
> >>>
> >>>.
> >>>
> >
> >
> >
> >
> > .
> >
>