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

[Dimitri Papadimitriou <dpapadimitriou@psg.com>]

hi jp,

see in-line:
> 
> Hi Dimitri,
> 
> At 02:45 AM 3/2/2004 +0000, Dimitri Papadimitriou wrote:
> >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."
> 
> 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.

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.
> Thanks
> 
> JP.
> 
> >thanks,
> >- dimitri.
> 
> 
>