[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Dimitri,

For the second time you are saying that I don't see the issue that you are
pointed out and this is beginning to annoy me.

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

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