Re: Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi,

At 09:21 PM 6/13/2004 +0100, Adrian Farrel wrote:
>Hi,
>
>Contrary to appearances, this discussion may be making progress.
>
>JP said,
>
> > > And I do not see why specifying the signalling method would be a problem
> > > at all. If a SP requires a contiguous LSP to avoid its LSP to be
> > > stitched along its path and potentially reoptimized without any HE
> > > control, specifying that the LSP must be contiguous (or not) is indeed
> > > the right method.
>
>There are three issues there.
>
>1. Is it a problem to specify the desired/required signaling method?
>
>There are two answers.
>a. There is no technical problem with providing this function.
>b. There are plenty of fears about the consequences of providing
>     this function. Dimitri and Vishal have listed some.
>
>2. Can a HE reasonably require control of functions such as
>     re-optimization?
>
>The answer to this would appear to be "yes". But note that this 
>requirement surely applies
>to all signaling methods. It happens to be the case that the option is 
>meaningless in
>contiguous signaling because the LSP cannot be optimized downstream of the 
>HE (using
>existing make-before-break techniques - but who knows what the future holds?).
>
>So here is a good example of a functional requirement ("re-optimization 
>only under
>head-end control") that the head-end should be able to signal. You should 
>make sure this
>is clear in section 7.9.
>
>3. Is there a reason to require contiguous signaling rather than some 
>other form?
>
>I still don't see one.

Well, you may not want a downstream SP to use stitching and potentially 
"hide" what happens downstream in term of reroute, failure, reoptimization, 
...

>Please understand that I am *NOT* saying that SPs have a perfect right to 
>control what
>signaling is used within their network. This is usually achieved through 
>the joint
>measures of procurement and configuration. An SP would be justifiably 
>vexed to discover
>that a cluster of LSRs within their network had autonomously switched LSP 
>setup requests
>to operate in CR-LDP.
>However, it is not true to say that when an ingress LSR sends an RSVP-TE 
>Path message it
>is requiring that that signaling technique be used all the way to the egress.
>
>The issue clearly gets fuzzy when the LSP traverses part of the network 
>that is out of the
>originating SP's direct control (i.e. another AS). But here we are talking 
>only about
>areas.

But as you know the solutions will apply to both inter-area and inter-AS.

Cheers

JP.


>Cheers,
>Adrian