[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi JL,

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

Regards,
-Vishal

> -----Original Message-----
> From: owner-te-wg@ops.ietf.org [mailto:owner-te-wg@ops.ietf.org]On
> Behalf Of LE ROUX Jean-Louis FTRD/DAC/LAN
> Sent: Friday, June 11, 2004 9:30 AM
> To: v.sharma@ieee.org; TE; CCAMP
> Subject: RE : Last call comments:
> draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
> Hi Vishal,
>
> Thanks a lot for these highly useful comments.
>
> Please see inline for some answers.
>
> Regards,
>
> JL
>

<snip>

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

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.

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

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


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

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.

> Basically we want to preserve IGP hierachy concept, are there
> 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.
>
> >
> >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

Ok, sure.


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


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

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

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.

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