[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