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)