[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 Vishal
Sorry for this delayed answer
See some additionnal comments inline
Regards,
JL
>-----Message d'origine-----
>De : owner-te-wg@ops.ietf.org
>[mailto:owner-te-wg@ops.ietf.org] De la part de Vishal Sharma
>Envoyé : vendredi 11 juin 2004 23:35
>À : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : 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.
Basically, as mentionned by JP, the signaling method used will have a non negligeable impact
on important features (Reoptimization, FRR, rerouting). For instance, if you use sitching or nesting, you will face FRR issues as regards ABR protection.
I agree that we could just signal the function/service
"FRR protection of ABRs", "Head-end Control of reoptimization"...
This would clearly require the "contiguous" signaling mode
IMHO, this is simpler to directly signal the signaling mode.
I don't really see any interop issue here. Basically if an ABR does not support the signaling mode, it simply rejects the LSP setup.
>
>
>> 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.
FRR interop issues was IMHO not related to this flag in the FRR object.
>
>> >
>> >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.)
Thanks
>
>
>> >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".
Basically 5.3 points out that information propagation for PATH-SELECTION
MUST continue to be localized.
It also means that we allow for the IGP to carry extra information provided that it is NOT topology related...
>
>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.
IMHO it is also useful to tell protocol designers what we don't want in our networks...
>
>> 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.
OK, in 8.2 the criteria is more qualitative than quantitative
>
>Also, even for 8.1, it may be good to add the = to explanation
>for (1) and (2) that you've given below.
OK
>
>> 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.
>>
>
Thanks again for these comments. We will post, on Monday, a new revision incorporating received comments.
Regards,
JL