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

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 16 Feb 2005 00:08:03 +0100

hi arthi and jp,

by reading this e-mail, i have several comments:

- section 3: why a TE link is to be associated to an LSP segment since 
at the end the segment exists only within the context of the end-to-end 
that triggers it, i.e. re-use of a segment is anyway not possible once 
created (unreserved bandwidth set to 0) so why other nodes would need to 
know about its existence ? other sections in this document do also refer 
to this but (see for inst. section 5.2) if the network sees the LSP 
segment as a TE link in their TE databases what does "computation of a 
path over this TE link." exactly means ?

- section 4: mentions "Although not adjacent in routing, the end nodes 
of the LSP segment will have a signaling adjacency and will exchange 
RSVP messages directly between each other." it would be interesting that 
you define what you mean by signaling adj. because imho such an adj. is 
based on the permanent exchange of hello msg

- section 4: the main difference between signaling an LSP over an LSP 
segment instead of over an FA-LSP is that no Labels are allocated and
exchanged for the e2e LSP over the LSP segment hop -> therefore there is 
a specific configuration/usage of the label_request object when 
signaling the end-to-end LSP (as well as the upstream label for bi-dir 
LSP) to be detailed here

- section 5.1: mentions "Similar to setup, tearing down the LSP segment 
may also be decided either via local configuration or due to the fact 
that there is no longer an e2e LSP stitched to the LSP segment." it 
would be interesting to detail the deletion sequence when initiated from 
the end-to-end LSP head-/tail-end and stitching head-/tail-end

thanks,
- dimitri.

[email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: LSP Stitching with Generalized MPLS TE
> 	Author(s)	: A. Ayyangar, J. Vasseur
> 	Filename	: draft-ayyangar-ccamp-lsp-stitching-00.txt
> 	Pages		: 12
> 	Date		: 2005-2-14
> 	
> In certain scenarios, there may be a need to combine together two
> different Generalized Multi-Protocol Label Switching (GMPLS) Label
> Switched Paths (LSPs) such that in the data plane, a single end-to-end
> (e2e) LSP is achieved and all traffic from one LSP is switched onto the
> other LSP. We will refer to this as "LSP stitching". This document
> covers cases where: a) the node performing the stitching does not
> require configuration of every LSP pair to be stitched together b) the
> node performing the stitching is not the egress of any of the LSPs c)
> LSP stitching not only results in an end-to-end LSP in the data plane,
> but there is also a corresponding end-to-end LSP (RSVP session) in the
> control plane. It might be possible to configure a GMPLS node to switch
> the traffic from an LSP for which it is the egress, to another LSP for
> which it is the ingress, without requiring any signaling or routing
> extensions whatsoever, completely transparent to other nodes. This will
> also result in LSP stitching in the data plane. However, this document
> does not cover this scenario of LSP stitching.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ayyangar-ccamp-lsp-stitching-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ayyangar-ccamp-lsp-stitching-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ayyangar-ccamp-lsp-stitching-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Arthi Ayyangar <[email-masked]>
Date: Tue, 15 Feb 2005 16:33:30 -0800 (PST)

Hi Dimitri,

Thanks for your comments. Please see my replies inline.

> path over this TE link." exactly means ?
---------> 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 ? The same reasons
and restrictions apply to the LSP segment as well.

> based on the permanent exchange of hello msg
-------> This terminology (signaling adjacency) itself is borrowed from
the hierarchy document. The sentence following it, simply tries to
explain what it really means in the context of this doc. I am okay with
removing the "signaling adjacency", if it doesn't make sense.

> signaling the end-to-end LSP (as well as the upstream label for bi-dir
----> Okay.

> the end-to-end LSP head-/tail-end and stitching head-/tail-end
-------> Okay.

thanks,
-arthi

---

From: dimitri papadimitriou <[email-masked]>
Date: Wed, 16 Feb 2005 07:58:56 +0100

hi arthi, see in-line for some clarifications

Arthi Ayyangar wrote:

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

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

> The same reasons and restrictions apply to the LSP segment as well.
> 
> 

well, in the LSP Hierarchy case, if one wants to maintain resilience 
against channel or software failures for the nested LSPs one needs to 
maintain a signaling adjacency (by exchanging hello messages by which 
the restart and recovery time will be exchanged between the tail and the 
head-end of the FA-LSP), in the present case, such construction could 
also be possible as the penultimate hop for inst. does not know about 
the details concerning the end-to-end LSP since the Path message was 
(during setup phase) sent directly to the LSP segment tail-end

>>the end-to-end LSP head-/tail-end and stitching head-/tail-end

i am ok for the rest

much thanks,
- dimitri.

> .

---

From: Alia Atlas <[email-masked]>
Date: Wed, 16 Feb 2005 12:31:44 -0500

Arthi,

In the draft, you discuss advertising a number of LSP segments as a TE link 
bundle.  At the same time, the egress of the LSP segments needs to be able 
to determine which of those LSP segments was intended - but this is based 
on the IF_ID RSVP_HOP (PHOP) object.  Could you clarify how this would work 
in combination with the link bundle?

Thanks,
Alia

---

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 16 Feb 2005 18:08:37 -0800 (PST)

Hi Dimitri,

Please see my replies (AA--->) inline.

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

> crossing anymore - so here the question is about definition and
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.

More on a) later.

thanks,
-arthi

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 17 Feb 2005 08:32:58 -0500

Dimitri, Arthi,
See my comments in line.

Igor

----- Original Message ----- 
From: "Arthi Ayyangar" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 16, 2005 9:08 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

> 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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Feb 2005 14:47:43 +0100

igor - see in-line

Igor Bryskin wrote:

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

you don't understand the question, it is do we have to consider as 
default behavior that a pre-provisioned is to be "advertized"

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 -

thanks,
- dimitri.

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 17 Feb 2005 10:37:41 -0500

Dimitri,
see my comment in line.

Igor

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: "Arthi Ayyangar" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 17, 2005 8:47 AM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Feb 2005 17:40:21 +0100

igor - see in-line

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

which flexibility are we expecting here, this "segment" can accommodate 
exactly one incoming request - additionally only nodes part of the same 
area can make use of this advertisement - 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 ?

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 ?

thanks,
- dimitri.

>>>>>while intermediate node terminates the SC corr. to the switching type
> 
> of
> 
>>>>AA--------> As far as trigger for setting up an LSP segment is
> 
> concerned,
> 
>>>>boundaries". I realize that the document doesn't discuss this,
> 
> especially
> 
>>>>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
> 
>>>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
>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> .
>

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 17 Feb 2005 12:39:18 -0500

dimitri, see in line.

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 17, 2005 11:40 AM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

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

so in fact what it would allow
> 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.
For instance, recall the discussions on P2MP and how we want use legacy LSRs
to be part of P2MP tunnels

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

Igor

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 17 Feb 2005 09:49:30 -0800 (PST)

Igor, Dimitri,

> configuration, receiving setup request for inter-domain LSP, other policies.
AA>--------> I agree...in fact I also absolutely agree that LSP segment
end points do NOT have to be domain boundaries. In fact there could be
other reasons for creating LSP segments spanning a bunch of nodes...one
application that has also been refered to in the document, say P2MP, for
preventing legacy LSRs from being in the path of P2MP tunnels.

thanks,
-arthi

---

From: Arthi Ayyangar <[email-masked]>
Date: Thu, 17 Feb 2005 09:58:57 -0800 (PST)

Igor, Dimitri,

> > area can make use of this advertisement -
AA-----> I agree with Igor...one of the reasons you advertise an FA is
to attract traffic over that FA, note that it is advertised with
TE metric = (TE metric of FA LSP path - 1) ..... I would think this would
also be the reason to advertise an LSP segment, IF this is desired. Again,
note that this decision is completely local to the node originating the
LSP segment and would be dictated by some policy.

> and advertise them (as bundles or individually) as TE links to be used for
AA----------> Agreed.

thanks,
-arthi

> to be part of P2MP tunnels
AA-------> Absolutely.

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Feb 2005 19:19:02 +0100

Igor Bryskin wrote:

>>>>>>>>due to arrival of an e2e LSP setup request itself. Similar to an FA,
> 
> an
> 
>>>>>>>i understand the point on pre-created <-> advertised but this
> 
> knowledge
> 
>>>>>>>node (part of the same area) receiving an incoming multi-area PSC-2
> 
> LSP
> 
>>>>>>>condition, but now once used relevance of the existence of the
> 
> segment
> 
>>>>>>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.
> 
>>>>>>were previously advertising it ? Don't you think that is a big hammer
> 
> ? E.g.
> 
>>>>>>the link is deleted from the database ? So, all the document says
> 
> today 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
> 
>>>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.
> 

it is exactly these purposes that i am looking for

> segments. I might want to use nodes that do not have proper signaling

what does that mean "proper signaling software"

> 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

> 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

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
> 
>>>>>>>[PSC-2,PSC-1], resp.), while in the LSP segment case we would have
> 
> now
> 
>>>>>>this discussion in the next revision. I think in case of LSP segment
> 
> the
> 
>>>>>boundary rather than on region boundary: nothing prevents creating a
> 
> VC4
> 
>>>FA
>>>
>>>

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Feb 2005 19:20:56 +0100

arthi

> preventing legacy LSRs from being in the path of P2MP tunnels.

for this specific point of stitching segments to "tunnel" P2MP branches, 
i thought we would make use of the node capability flags to determine 
the head and tail-end of the segment - is that assumption still being 
considered ?

thanks,
- dimitri.

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Feb 2005 19:34:26 +0100

> LSP segment and would be dictated by some policy.

i obviously understand that policy triggers of not such behaviour, the 
issue i point out is one of the case that could be of interest for inst. 
multiple path comp. domains within the same area generate the issue of 
the flooding scope within that area (as the computational domain does 
not scope the flooding) for the purpose being of attracting on specific 
segments how to prevent node within the inner "domain" to make use of 
these segments

this said, in case an advertisement is to be considered rules should 
also be defined in terms of parameters that would require to be inherited

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 17 Feb 2005 14:38:41 -0500

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" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 17, 2005 1:19 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Feb 2005 21:55:38 +0100

igor,

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

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

> The specific example is using LSRs that
> 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 -

> What if I don't want them to be dynamically created and rather

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)

> that can perform path computation with such contraint on path segments

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)

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

>>>>>>>>>>---------> 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
>>>
>>>
>>>>>>>>>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
> 
>>>>>>>>>links with PSC-2 (one of these being the LSP segment) then a
> 
> another
> 
>>>>>>>>>request may start making use of this segment to join the next
> 
> border,
> 
>>>>>>>>>is not a useful information (for the area) as there is no
> 
> possibility
> 
>>>>>>>>were previously advertising it ? Don't you think that is a big
> 
> hammer
> 
>>>? E.g.
>>>
>>>
>>>>>>>>segment differentiate this event from an LSP segment down event
> 
> where
> 
>>>>>>>>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
>>>
>>>
>>>>>>now beside the fact that there are techniques to do so what would be
> 
> the
> 
>>>IB>> Disagree - the segment could be a component link within a bundle.
> 
> In
> 
>>>IB>> Who said that sticthing segments must necessarily terminate on
> 
> domain
> 
>>>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.
>>
>>>For instance, recall the discussions on P2MP and how we want use legacy
> 
> LSRs
> 
>>>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
> 
>>>>>>>>>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
> 
>>>>>>>>given that we are doing other comparisons with FA LSPs. So, I will
> 
> add
> 
>>>>>>>>trigger for LSP segment setup would come from a) successful
> 
> switching
> 
>>>>>type
>>>>>
>>>>>
>>>>>
>>>>>>>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
>>>>>
>>>>>
>>>>>

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 17 Feb 2005 16:43:14 -0500

Dimitri,

See my comments in line.

Igor

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 17, 2005 3:55 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

> also depends what do you mean by statical provisioning ?

IB>> I have segments that are provisioned/owned by the management plane

> 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

> discussion - afaik the working group has (still) to provide requirements

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

> segment related information is equivalent to the corresponding links

IB>> Dynamic establishment of the stitching segments may fail

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

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.

Igor

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 17 Feb 2005 23:33:41 +0100

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?
>>>
>>>1) How else are you going to use statically provisioned segments as part
>>> of dynamically provisioned end-to-end LSPs ?
>>

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

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)

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

and so just to be clear if they are not useful for e2e signaling what is 
the purpose of advertising them for this purpose ?

>>>have them pre-provisioned to spead up the process of p2mp tunnel setup
>>>and decrease blocking probability?
>>

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

this may be the case but once known explicit label control on each link 
is enough to assume continuity

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

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

>>>>>>>>>>>>pre-created, it could be advertised, in which case other nodes
> 
> may
> 
>>>>>>>>>>>>compute a path over it.
>>>>>>>>>>>>
>>>>>>>>>>>node (part of the same area) receiving an incoming multi-area
> 
> PSC-2
> 
>>>>>LSP
>>>>>
>>>>>
>>>>>
>>>>>>>>>>But would you rather stop advertising the link at this point, if
> 
> you
> 
>>>>>>>>>>how would a head end which has indeed computed a path over that
> 
> LSP
> 
>>>>>>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>>>>>IB>> Completley agree with Arthi. Besides, several parallel
> 
> stitching
> 
>>>>>>>>>advertised link by one LSP does not necessarily take away all
> 
> link's
> 
>>>>>>>>>bandwidth.
>>>>>>>>
>>>>>>>the sticthing FA-LSP (the same layer FA-LSP) and FA-LSP created in
> 
> the
> 
>>>>>lower
>>>>>
>>>>>
>>>>>
>>>>>>>>purpose of it ? and what it the overhead that such advertisement
> 
> would
> 
>>>>>>which flexibility are we expecting here, this "segment" can
> 
> accommodate
> 
>>>>>>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
> 
>>>>>>because it represents a lower region LSP (with usually a given ratio
> 
> of
> 
>>>>>>case of a segment i do have some difficulties to excatly see where
> 
> this
> 
>>>>>advertised as as single FA, how it would be different from the
> 
> bandwidth
> 
>>>>>>>>>>>per LSP-Hierarchy mandates crossing LSP region border: the
> 
> head-end
> 
>>>>>and
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>tail-end switching capability represent the SC of the resulting
> 
> TE
> 
>>>>>link
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>[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
> 
>>>>>>>>>>this discussion in the next revision. I think in case of LSP
> 
> segment
> 
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>>>>>and switching capability match and b) some local policy on the
> 
> node
> 
>>>>>>>which
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>

---

From: "Igor Bryskin" <[email-masked]>
Date: Fri, 18 Feb 2005 08:51:50 -0500

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.

> 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" <[email-masked]>
To: "Igor Bryskin" <[email-masked]>
Cc: <[email-masked]>; "Arthi Ayyangar"
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 17, 2005 5:33 PM
Subject: Re: I-D ACTION:draft-ayyangar-ccamp-lsp-stitching-00.txt

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 19 Feb 2005 03:34:00 +0100

igor:

Igor Bryskin wrote:
> stitching segments as FAs. 

i was referring to such segment as and edge-to-edge LSP signaled using 
RFC 3473 - i was not under the impression this document intended to 
cover any other case -

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

what do you mean by "who is the user ?" ... it is imho obvious that the 
only "user" for a LSP segment being part of the stitching operation is 
the end-to-end LSP

> is some other mechanism (which you were not specific about) 

i think this is spelled out as part of RFC 3473

> that makes possible using the statically provisioned segments.

but i do not call this "LSP stitching" as no one did ever rely on this 
mechanism to make use of a statically provisioned subnetwork since at 
the end at the discretion of its owner - the wg is involved into the 
present discussion because we are assuming intermediate nodes (i.e. part 
of the segment) being GMPLS (RFC 3473) capable

> signal such LSP? If yes, do I need TED in this case?

obviously this is not the comment i made here - the comment is "if not 
useful for end-to-end multi-domain LSP what is the purpose of this 
advertisement"

>>>>>1) How else are you going to use statically provisioned segments as
> 
> part
> 
>>>>>nodes that are going to be involved in end-to-end dynamically
> 
> provisioned LSPs
> 
>>>IB>> The point is that transit nodes of the segments do not participate
> 
> and
> 
>>>>>the PCE computing p2mp tree may take in consideration the advertised
> 
> node
> 
>>>>>segments even if the overall cost of such LSPs would be higher than if
> 
> they would
> 
>>>>>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.
>>>>
>>>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
> 
>>>It is much simpler to pre-provision such OEO-OEO segments and advertise
> 
> them
> 
>>>>>>>>>>>>>>---------> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>therefore advertisement of the LSP segment may create a
> 
> multi-hop
> 
>>>>>>>>>>>>>to make re-use of it except when the end-to-end LSP is torn
> 
> down
> 
>>>>>>>>>>>>into an LSP segment it is no longer usable by other nodes in
> 
> that
> 
>>>>>>>area.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>the link is deleted from the database ? So, all the document
> 
> says
> 
>>>>>>>today is
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>not different from a FA-LSP being consumed...in that case we
> 
> don't
> 
>>>>>>>stop
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>segments could be advertised as a single bundle - hence, using
> 
> the
> 
>>>>>>>>>to advertise//remove FA TE link is a policy driven carefully
> 
> thought
> 
>>>>>>>through
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>>>IB>> Disagree - the segment could be a component link within a
> 
> bundle.
> 
>>>>>In
>>>>>
>>>>>
>>>>>
>>>>>>>and advertise them (as bundles or individually) as TE links to be
> 
> used
> 
>>>>>for
>>>>>
>>>>>
>>>>>
>>>>>>>specific TE purposes.
>>>>>>
>>>>>>>>receiving the request re-orients its request to the head-end for
> 
> this
> 
>>>>>>>>advertisement
>>>>>>>>                      |
>>>>>>>>you would have a segment between A-B that could be reached from C
> 
> (the
> 
>>>>>>>For instance, recall the discussions on P2MP and how we want use
> 
> legacy
> 
>>>>>LSRs
>>>>>
>>>>>
>>>>>
>>>>>>>>unreserved bandwidth that makes worth advertizing the FA link) but
> 
> in
> 
>>>>>>>IB>> Again, if you imagine that several parallel sticthing segments
> 
> are
> 
>>>>>>issues are different - FAs are used in manner to preferentially
> 
> attract
> 
>>>>>>>In fact it would be even more useful, because in case of lower layer
> 
> FA
> 
>>>>>you need also
>>>>>
>>>>>
>>>>>
>>>>>>probably there is a need to go in more detailed examples before
> 
> drawing
> 
>>>>>>>>>>>>>a more technical point is related to the definition of an FA
> 
> LSP
> 
>>>>>>>which
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>>while intermediate node terminates the SC corr. to the
> 
> switching
> 
>>>>>type
>>>>>
>>>>>
>>>>>
>>>>>>>>>of
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>capable network with first and last link being [PSC-1,PSC-2]
> 
> and
> 
>>>>>>>>>>>>given that we are doing other comparisons with FA LSPs. So, I
> 
> will
> 
>>>>>add
>>>>>
>>>>>
>>>>>
>>>>>>>>>>>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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>.
>>>>>>>>>
>>>>>>>>
>>>>>>>.
>>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>
> 
> 
> .
>