Subject: thoughts on draft-vasseur-ccamp-inter-area-as-te-00.txt

From: Dimitri Papadimitriou <[email-masked]>
Date: Tue, 2 Mar 2004 02:45:34 +0000 (GMT)

hi arthi, jp, all,

reading draft-vasseur-ccamp-inter-area-as-te-00.txt
the following came into my mind, why is there a need
to signal the "signaling method": contiguous versus
stitching vs nesting ? 

the reason provided in the document about "control" 
is unclear, is the sensitivity of the carried traffic
dependent of the signaling method ? 

"For the sake of illustration, a Head-end LSR, may 
desire to prevent stitching or nesting for a traffic 
sensitive inter-area/AS TE LSPs that require a path 
control on the head-end LSR."  

it seems for me that "signaling the signaling method" 
introduces here in addition to the protocol issue(s),  
policy issues:

"Ox01: Contiguous LSP [...]

When set, this indicates that a boundary LSR MUST 
not perform any stitching or nesting on the TE LSP 
and the TE LSP MUST be routed as any other TE LSP 
(it must be contiguous end to end). [...]

A mid-point LSR not supporting contiguous TE LSP 
MUST send a Path Error message upstream with error 
sub-code=17 Contiguous LSP type not supported."

thanks,
- dimitri.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Mon, 01 Mar 2004 22:21:38 -0500

Hi Dimitri,

>sub-code=17 Contiguous LSP type not supported."

because when crossing multiple ASes this allows the head-end signalling a 
contiguous LSP to make sure that it will not be stitched in some downstream 
domain hence keeping some strict control about the reoptimization. This has 
to be done on a per-LSP basis, since the same head-end may not impose any 
such requirement for other inter-area/AS LSPs.

Thanks

JP.

---

From: Dimitri Papadimitriou <[email-masked]>
Date: Tue, 2 Mar 2004 16:24:44 +0000 (GMT)

hi jp,

> such requirement for other inter-area/AS LSPs.

not sure i understand that what you want to achieve requires
the method that you are proposing here: in the hypothetical
case of multi-as/area reoptimization, what you say is "i want
to keep head-end control for the re-optimization of a multi-
area/asn LSP"

so here, why don't you use a flag saying "head end control 
of re-optimization" meaning we define a method such that the
head-end decides its willingness to keep control of the re-
optimization occurrence and upon notification could decide 
about when this has to be committed and this *independently* 
of the LSP provisioning method for this LSP 

in the meanwhile this would allow to be more efficient about
the way each ingress boundary LSR decides about the method to 
deliver the incoming request constraints 

so, in brief define a method that would avoid constraining the 
provisioning method from the head-end as/area perspective to 
its downstream as/area for an hypothetical re-optmization that 
is in any case under the control of the local domain, and this
in particular the local as)

ps: unfortunately you're not attending this ietf meeting so 
that we can't discuss this important issue during the ccamp 
face-to-face meeting

thanks,
- dimitri.

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Thu, 04 Mar 2004 14:28:35 -0500

Hi Dimitri,

>in particular the local as)

Well, no, the intention here is really to offer to the head-end the ability 
to specify (just as any other LSP attributes) the signalling method that 
must be used in other downstream area/AS (note that this is clearly a SP 
requirement). Indeed, the reoptimization is just one component but there 
are also other aspects related to the signalling method in use. Hence, the 
aim of this bit is indeed to specify the signalling type of the 
inter-area/AS TE LSP.

thanks for your comments

JP.