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

From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[email-masked]>
Date: Fri, 11 Jun 2004 18:30:16 +0200

Hi Vishal,

Thanks a lot for these highly useful comments.

Please see inline for some answers.

Regards,

JL

>-----Message d'origine-----
>De : Vishal Sharma [mailto:[email-masked]] 
>Envoyé : jeudi 10 juin 2004 03:16
>À : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : Last call comments: 
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Hi Jean-Louis et al,
>
>I have reviewed the above draft quite carefully, and it is
>a very useful document. Nice work!
>
>There are several comments I have as part of last call, I'm 
>giving these below as technical and editorial, to make 
>discussion easier.
>
>Thanks,
>-Vishal 
>********************************************************************8
>
>Technical
>-----------
>
>1. Sec. 1, Introduction.
>"The set of MPLS traffic engineering tools," is probably 
>better worded as "The set of MPLs traffic engineering 
>components," as the phrase "MPLS traffic engineering tools" is 
>liable to be confused with planning and traffic engineering 
>tools/software (a la Netscope, NPAT, SPGuru, MATE, etc.).

Agree

>
>2. In the same section, how are the components useful for 
>aggregated traffic measurement? Is it because, OSPF-TE and 
>IS-IS TE may be used to convey parameters like aggregate link 
>utilization? What else is included here?

Basically TE-LSPs offer an easy mean to measure the traffic matrix.
By accounting packets forwared into a TE-LSP you can deduce the traffic rate 
between two end-points.
Some ISPs use a mesh of TE-LSP as a simple way to measure trafic matrix

>
>3. It would be good to have terms like "traffic engineering 
>components", "traffic engineering mechanisms" and "traffic 
>engineering tools" defined in the terminology section to clear 
>distinguish between them, and avoid confusion when reading and 
>interpreting this document.

Agree, will be done in next revision. 
As suggested by Adrian, we will also add a section summarizing MPLS-TE components (routing, path computation, signaling).
This will help explaining current limitations and inter-area requirements.

>
>4. Sec. 4.1.3, para 1, not sure what "traffic sensitive 
>applications" means. It might be better worded as "performance 
>sensitive applications" or "quality sensitive applications."

Agree, "quality sensitive application" is better

>
>5. Sec. 4.2, option 3, it would be nice to have a phrase 
>explaining why this is different than LSP hierarchy.
>

OK, will add a phrase to clarify: Basically here there is no FA-LSP advertisement

>6. Sec. 6, para 4, "pseudo wire connections" should really be 
>just "pseudo wires"

OK

>
>7. Sec. 7.2, I tend to agree with Adrian that (ideally) it 
>would seem it should be enough for the head-end to signal the 
>function/service it wants and not the underlying method used 
>by nodes further in path to provide that service. If, as you 
>mention, this is a requirement expressed by many SPs, it would 
>be good to understand why it is so, and for the document to 
>explain a bit about it.

Actually I don't really understand the objection on that point.
The requirement seems clear for me. If there are several methods supported in my network, I want to select the method on a per LSP basis in order to have entire control on how the LSP is signaled. This will ease LSP management.
Basically there won't be hundreds of methods but just two or three (contiguous, stiching, nesting..)
So it seems quite relevant to have the ability to signal the desired method.

Let's have a look at the FRR draft: There are two modes defined, and the desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within the FRR object). I did not see any objection on that.

>
>8. Sec. 7.3 on path optimality talks only of the optimality
>of a single path computed in isolation. What is the definition 
>of optimality to be applied for computing diverse paths? (Sec. 
>7.7 later does not specifically discuss this aspect either.) 
>If one used CSPF in sequence to compute two diverse paths (as 
>this section would imply) then the computation may fail, even 
>though a set of optimal diverse paths exists (as acknowledged 
>in Sec. 7.7 ahead).

Agree, we should add a definition of optimality to be applied when computing diverse path
This maybe: A placement of two diverse paths is optimal if their cumulative cost is minimal.

>
>9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to 
>underscore Adrian's point on specifying the scaling 
>requirements themselves (with respect to areas, amount of 
>flooded info. etc.) rather than the realization of those 
>requirements (by not adding any info. to the LSAs, for example).

It seems that you are OK with 5.3 (no comments)
"Containment of routing information MUST not be compromised to allow inter-area traffic 
   engineering. Information propagation for path-selection MUST continue 
   to be localized.". 
Thus you should also be OK with 7.4

Basically we want to preserve IGP hierachy concept, are there objections to that point ?
This means, for ISPs contributing to this draft, "no leaking of any topology related info accross areas". 
Of course, this does not preclude the addition of info to the LSA, provided that it is not topology related.

>
>If solutions can meet the scaling requirements by adding a bit 
>of info. to the IGP, I think this should be allowed, otherwise 
>there is really not much that could be achieved using current 
>mechanisms (since no modifications to them seem permissible, 
>and we already established that these, as they exist, do not 
>provide for adequate inter-area MPLS TE).
>
>BTW, one of the points made in this regard in these
>email thread was about the use of path computation servers, 
>which can supposedly compute optimal paths without any impact 
>on the IGP.
>
>I think this argument isn't quite complete, since it hides the 
>signaling extensions required for these as well as the 
>scalability impact of recursive PCE-type schemes (btw, this 
>was a question that came up in independent discussions with JP 
>in the context of the ARO and PCE schemes, and is still under 
>discussion).

Let's continue this discussion in another thread addressing solutions

>
>10. Sec. 7.6, the figure O(N^2) makes the assumption that
>each of the N ARBs at the border of the neighboring areas is 
>connected to each other ABR. No? In reality, the number of 
>crankback's may be significantly less therefore.

No, basically if you have X1 ABRs in head-end area and X2 ABRs in tail-end area you may 
have up to X1*X2 crankbacks, provided that there is a path between all
ABRs. This does not assume direct connectivity between ABRs.

>
>11. Sec. 7.7, I guess it would be useful to qualify what is 
>considered "extra-load" in signaling and routing here. Is that 
>to be interpreted as _absolutely no change_ to current 
>signaling and routing protocol objects? 

No, this should not be interpreted as "absolutely no change".
Basically the solution must respect scalability requirements spelt out in 5.2
Will clarify in next revision.

>seem feasible, if inter-area routing/TE is to be achieved, so 
>something more specific is implied, which would be good to spell out.
>
>BTW, also tend to agree with Adrian's point that this section 
>seems to be describing the computation of diverse paths rather 
>than the establishment of diverse paths, which would seem to 
>be the requirement.

Yes this is basically a requirement on computation, but in this inter-domain context
Path computation and Path establishment are no longer necessarily independant (see your ARO proposal)

>
>12. Sec. 7.9, what is meant by "inter-area head end LSR"?
>An LSR that is the head-end of an inter-area LSP (that is, an 
>LSP traversing multiple areas)?

Yes, will reword

>
>13. Sec. 8.2, not sure that is providing a real measurable 
>evaluation criterion. If it is to be kept, some specifics 
>should probably be given.

IMHO what we list is clearly measurable
   (1) Optimality of the computed inter-area TE LSP path. 
= Computed cost - Shortest cost 
   (2) Optimality of the computed backup tunnel path protecting against  
       the failure of an ABR, capability to share bandwidth among backup  
       tunnels protecting independent facilities 
= Total backup bandwidth consumption
   (3) Inter-area TE LSP set up time.
 = clearly measurable
   (4) RSVP-TE and IGP scalability (state impact, number of messages,    
       message size) 
 = Memory footprint increase, CPU load increase, Message size Increase...This is also definitely measurable.

>
>
>Editorial
>-----------
>
>Below phrases between _xxxx_ are added, and between <xxxx> are 
>to be removed.
>
>1. Sec. 1, Introduction, ", that supports ..." --> "which supports ..."
>
>2. Sec. 4, para 1, line 4, "This section is intended to help 
>_in_ defining ..."
>
>3. Sec. 4.1.1 --> "Intra-area _resource_ optimization"
>
>4. Sec, 4.1.1. line 1 --> "MPLS-TE can be used within an area 
>to redirect paths of aggregated flows away from over-utilized 
>resources within a network."
>
>5. Sec. 4.1.1., para 2 -->
>"In this way, MPLS-TE allows for greater control _over_ how 
>traffic demands _are routed over_ <utilize> a network 
>topology, and _utilize a network's resources_"
>
>5. Sec. 4.1.1., para 2 --> "As mentioned in Section 1, uses
>   to date have been limited to <within> a single IGP area."
>
>6. Sec. 4.2, option 4, what are the numbers (2) and (3) in brackets?
>
>7. Sec. 5.1, para 6, "one possible approach could consist _of_ 
>deploying ..."
>
>8. Sec. 5.2, I am not sure why there is a small subsection 
>itself titled "Requirements for inter-area MPLS TE", when the 
>entire document is about this subject? Is the intent here to 
>motivate the need for inter-area MPLS TE? If so, maybe it 
>should say "Motivations for inter-area MPLS TE"?

Thanks a lot for these editorial comments

>
>These a few of the ones that I caught. In general, I feel the 
>document would benefit from a thorough editorial review of 
>writing, that would help to eliminate some awkward 
>constructions and redudancy in several places.
>
>

Agree, will do that for next revision.

Again thanks a lot Vishal, for these highly relevant comments

Regards,

JL

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 11 Jun 2004 18:43:07 +0100

Hi,

>The requirement seems clear for me. If there are several methods
>supported in my network, I want to select the method on a per
>LSP basis in order to have entire control on how the LSP is
>signaled. This will ease LSP management.

But WHY do you want to control the method?

Is it because you believe one of the methods is (may be) sub-functional? If that is the
case, why do we standardise it?

Is it because the methods have different applicability? That is, the methods are suitable
to different functional service requests? If so, why don't you specify the service request
and leave the network to provide the service.

> Basically there won't be hundreds of methods but just two or three
> (contiguous, stiching, nesting..).

Yes. Hopefully :-)

> So it seems quite relevant to have the ability to signal the desired method.

It would really help  to give an example where not being able to control the method would
break the ability to provide the requested service.
(Hint: I think I found one while looking at inter-domain protection paths. But that is a
fairly extreme situation.)

I have serious concerns that allowing this approach means that we risk inter-operability
disconnects.

> Let's have a look at the FRR draft: There are two modes defined, and the
> desired mode (one-to-one or bypass) is signaled on a per-LSP basis (within
> the FRR object). I did not see any objection on that.

I don't think holding the FRR draft up as a shining example is particularly wise.

Given that two solutions were included in the document (because the authors/WG could not
agree on a single solution?) and given that those solutions impacted the service provided
to the service requester it was necessary to allow the requester to control the solution.
In this case, controling the solution is equivalent to controling the service.

Note that this feature raises interoperability questions for FRR-enabled networks.

If, as I say, you are able to demonstrate that the inter-domain solutions impact the
service, then you may be on to something.

>Thus you should also be OK with 7.4

Or conversely? :-)

> objections to that point ?

None has been vocalised.

> Of course, this does not preclude the addition of info to the LSA,
> provided that it is not topology related.

So, for example, you would not be opposed to an LSA that described "aggregated TE
reachability information"?

Enjoy,
Adrian

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Fri, 11 Jun 2004 14:18:30 -0400

Hi Adrian,

>and leave the network to provide the service.

well, you may want different method for different LSPs ! Thus the 
requirement for signalling the required method.

Cheers,

JP.

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 11 Jun 2004 12:35:37 -0700

Hi JP at al,

Comments in-line.

-Vishal

> -----Original Message-----
> From: Jean Philippe Vasseur [mailto:[email-masked]]
> Sent: Friday, June 11, 2004 11:19 AM
> To: Adrian Farrel
> Cc: LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked]; TE; CCAMP
> Subject: Re: Last call comments:
> >to different functional service requests? If so, why don't you
> specify the
> >service request

I think that is the question precisely. Namely, why would a provider
want to control the exact method of how a specified service is provided?

It would seem to me that providers and their customers would agree on
a well-defined service. When signaling a request for the service, the
provider
HE equipment would specify the service (in some agreed upon standard format,
which would be standardized based on requirements in a document such as
the one we are discussing),
and would leave it to the intermediate routers/LSRs to figure out using
which method they can best provide that service.

I am not sure how having complete control over how an LSP is signaled
given the carrier any better ability to provide a given service.

It may be the case, for instance, that the provider chooses a given method
X as the choice to ask for a service A. However, given the network
situation,
it may be that method Y is the one able to provide the specified service,
where as X is not. What happens then? The request fails, and the provider
now has to retry with a different choice of method. By contrast, if the
service was specified, with the intermediate LSRs deciding how to provide
it, the request would be fulfilled in the initial instance.

-Vishal

---

From: "Vishal Sharma" <[email-masked]>
Date: Fri, 11 Jun 2004 14:35:28 -0700

Hi JL,

Thanks for the clarifications. A few follow-up thoughts in-line.

Regards,
-Vishal

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of LE ROUX Jean-Louis FTRD/DAC/LAN
> Sent: Friday, June 11, 2004 9:30 AM
> To: [email-masked]; TE; CCAMP
> Subject: RE : Last call comments:

<snip>

> supported in my network, I want to select the method on a per LSP
> basis in order to have entire control on how the LSP is signaled.
> This will ease LSP management.

As I explained in my email to JP, it is still somewhat unclear
as to what the ability to signal the desired method buys the
provider, and exactly why or how that simplifies LSP management.

> Let's have a look at the FRR draft: There are two modes defined,
> and the desired mode (one-to-one or bypass) is signaled on a
> per-LSP basis (within the FRR object). I did not see any
> objection on that.

I think the FRR draft is really a solutions draft, and it presents
two solutions which offer somewhat different services, in my view.
The detour provides the ability to protect segments of a _given_
LSP, while the bypass tunnel provides the ability to simultaneously protect
_multiple_ LSPs sharing a given resource (node(s) or link).

Also, as Adrian mentioned, it has lead to interop issues.

> cumulative cost is minimal.

Yes, this is one definition. I think in  some previous email
exchanges, Fabio had provided a good definition of optimality
for diverse path routing. (I'll try to dig it up in the
archives, and post a note separately on it.)

> Thus you should also be OK with 7.4

Actually, 5.3 imposes a requirement to preserve IGP hierarchy and
scalability,
but at least leaves open the possibility for the IGP to carry extra
information
as long as it is not an
"unreasonable amount of extra information" that does not "unreasonably
increase
IGP flooding frequency".

I thought 7.4 should probably provide some specifics on what unreasonable
is, and leave it to the protocol designers to devise protocols that keep
within those limits.
Instead it seems to prescribe a realization -- one where no topology
related info. of any sort should be added to the IGP LSAs.

> objections to that point ?

Depends on whether you want to preserve it in spirit or to the
letter :-).
I think it may be useful to give protocol designers some
wiggle room.

> This means, for ISPs contributing to this draft, "no leaking of
> any topology related info accross areas".
> Of course, this does not preclude the addition of info to the
> LSA, provided that it is not topology related.
>
> >

Ok, sure.

> ABRs. This does not assume direct connectivity between ABRs.

Ok, thanks. I see now what you are saying.

> >should probably be given.

JL, sure. The perf. requirements are given in Sec. 8.1, but I was
looking at Sec. 8.2.

Also, even for 8.1, it may be good to add the = to explanation for (1)
and (2) that you've given below.

>  = Memory footprint increase, CPU load increase, Message size
> Increase...This is also definitely measurable.
>

---

From: Arthi Ayyangar <[email-masked]>
Date: Fri, 11 Jun 2004 16:08:04 -0700 (PDT)

Hi,

IMO it should suffice to request the service instead of specifying which
signaling method to use to deliver that service. As Vishal mentioned,
different networks may use different methods to deliver the same service.
In fact, each network may have its own motivations to choose one method
over the other, for whatever reasons, and that should be fine.

I don't see how a HE equipment can grasp the various considerations and
limitations of some other network. I understand that there is need to
request a service per LSP, but I don't see how equating a type of
service to a signaling method buys us anything.

Instead, if we invest some effort into making sure that the requested
service is understood and first identify what parameters constitute this
service and put in processing rules or ways for the downstream node to map the
incoming request to a service definition, it may help.

thanks,
-arthi

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Sat, 12 Jun 2004 10:48:39 -0400

Hi,

>incoming request to a service definition, it may help.

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 could be many potential implication of the signalling method 
and trying to specify an SLA covering all of them would not quite hard to 
achieve.

Thanks

JP.

---

From: [email-masked]
Date: Sat, 12 Jun 2004 17:47:01 +0200

hi jp,

Jean Philippe Vasseur wrote:

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

as already mentioned just provide an indication to maintain the "head- 
end control for re-optimization" letting to the head end the control of 
this operation but this is orthogonal to the signaling method

i think the issue you're looking at can be sum'ed up as is there a case 
where you are not able to control the signaling method would preclude 
the ability to provide the required service (adrian had the same remark 
here and i want to underline that this issue is going now since the 
first time this document has been issued)

> There could be many potential implication of the 
> signalling method and trying to specify an SLA covering all of them 
> would not quite hard to achieve.

while for the time being there is some questioning about above mentioned 
  condition, i definitely see lot's of drawbacks in signaling 
(controling) the signaling method - example is that for instance leaving 
the control to the head-end for re-optimization (contiguous) precludes 
optimization in terms of number of LSPs to be maintained at each 
intermediate node (no nesting) so in brief you'd be optimizing only one 
dimension in the detriment of others

thanks,
- dimitri.

>> specify the service request
>> and the

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 13 Jun 2004 21:21:25 +0100

Hi,

Contrary to appearances, this discussion may be making progress.

JP said,

> > control, specifying that the LSP must be contiguous (or not) is indeed

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.

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.

Cheers,
Adrian

---

From: Jean Philippe Vasseur <[email-masked]>
Date: Mon, 14 Jun 2004 11:41:24 -0400

Hi,

>3. Is there a reason to require contiguous signaling rather than some 

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

>originating SP's direct control (i.e. another AS). But here we are talking 

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

Cheers

JP.

---

From: "Vishal Sharma" <[email-masked]>
Date: Mon, 14 Jun 2004 08:47:35 -0700

JP, Adrian, et al,

Quick question in-line.

-Vishal

> Sent: Monday, June 14, 2004 8:41 AM
> To: Adrian Farrel
> Cc: [email-masked]; [email-masked]; Arthi
> Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; [email-masked]; TE; CCAMP
<<snip>>

> >originating SP's direct control (i.e. another AS). But here we 
> are talking 
> >only about
> >areas.
> 

Actually, this is something that I've been wondering about as the
discussion on inter-area has progressed. Is there expected to be a 
separate document detailing inter-AS requirements?

Given that the framework and other related drafts are jointly addressing
inter-area and inter-AS issues, how come the requirements document(s) is
not? 

Perhaps I missed some of this evolution, but if someone could shed some 
light on this, that would be appreciated.

---

From: "Vishal Sharma" <[email-masked]>
Date: Mon, 14 Jun 2004 08:55:37 -0700

Folks,

Please ignore my previous question. I had read JP and Raymond's draft
a while ago, but completely forgot that it is the WG document addressing
inter-AS requirements!

-Vishal

> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Monday, June 14, 2004 8:48 AM
> To: Jean Philippe Vasseur; Adrian Farrel
> Ayyangar; LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
> Subject: RE: Last call comments:
> > >The issue clearly gets fuzzy when the LSP traverses part of 
> the network 
> > >that is out of the

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 14 Jun 2004 17:53:59 +0100

Hi again,
At the risk of flogging this one further than is reasonable...

> "hide" what happens downstream in term of reroute, failure, reoptimization,

Of the things you list, only reoptimization is specially hidden by stitching.

Repair/recovery mechanisms are already "hidden", or can be.

Perhaps something that you want here is some statement on inherritance rules. That is, the
relationship between the parameters of the end-to-end LSP and the stitched or tunnel LSP
that supports it.

That would be reasonable to define (see the inter-domain framework draft that tries to
point this out).

But so far you are repeatedly saying that there are functions that the ingress has a right
to control (which is fine) and that the way it should do this is by limiting how the
network provides signaling (which is not fine). Why is it not acceptable to you to specify
the functions that the LSP must support?

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

Well, I venture to suggest that areas all belong to the same administrative domain and so
are under the administrative control of the initiating SP.

Adrian