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 : [email protected]=20
>[mailto:[email protected]] De la part de Vishal Sharma
>Envoy=E9 : vendredi 11 juin 2004 23:35
>=C0 : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : RE: RE : Last call comments:=20
>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: [email protected] [mailto:[email protected]]On
>> Behalf Of LE ROUX Jean-Louis FTRD/DAC/LAN
>> Sent: Friday, June 11, 2004 9:30 AM
>> To: [email protected]; TE; CCAMP
>> Subject: RE : Last call comments:=20
>> 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=20
>would seem=20
>> >it should be enough for the head-end to signal the function/service=20
>> >it wants and not the underlying method used by nodes=20
>further in path=20
>> >to provide that service. If, as you mention, this is a requirement=20
>> >expressed by many SPs, it would be good to understand why it is so,=20
>> >and for the document to explain a bit about it.
>>
>> Actually I don't really understand the objection on that point. The=20
>> requirement seems clear for me. If there are several methods=20
>supported=20
>> in my network, I want to select the method on a per LSP=20
>basis in order=20
>> to have entire control on how the LSP is signaled. This will=20
>ease LSP=20
>> management. Basically there won't be hundreds of methods but=20
>just two=20
>> 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=20
>as to what the ability to signal the desired method buys the=20
>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=20
>> the desired mode (one-to-one or bypass) is signaled on a=20
>per-LSP basis=20
>> (within the FRR object). I did not see any objection on that.
>
>I think the FRR draft is really a solutions draft, and it=20
>presents two solutions which offer somewhat different=20
>services, in my view. The detour provides the ability to=20
>protect segments of a _given_ LSP, while the bypass tunnel=20
>provides the ability to simultaneously protect _multiple_ LSPs=20
>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.=20


>
>> >
>> >8. Sec. 7.3 on path optimality talks only of the optimality of a=20
>> >single path computed in isolation. What is the definition of=20
>> >optimality to be applied for computing diverse paths? (Sec.=20
>7.7 later=20
>> >does not specifically discuss this aspect either.) If one used CSPF=20
>> >in sequence to compute two diverse paths (as this section would=20
>> >imply) then the computation may fail, even though a set of optimal=20
>> >diverse paths exists (as acknowledged in Sec. 7.7 ahead).
>>
>> Agree, we should add a definition of optimality to be applied when=20
>> computing diverse path This maybe: A placement of two=20
>diverse paths is=20
>> optimal if their cumulative cost is minimal.
>
>Yes, this is one definition. I think in  some previous email=20
>exchanges, Fabio had provided a good definition of optimality=20
>for diverse path routing. (I'll try to dig it up in the=20
>archives, and post a note separately on it.)

Thanks=20

>
>
>> >9. Sec. 7.4 "Inter-area MPLS TE Routing" I would like to underscore=20
>> >Adrian's point on specifying the scaling requirements themselves=20
>> >(with respect to areas, amount of flooded info. etc.)=20
>rather than the=20
>> >realization of those requirements (by not adding any info. to the=20
>> >LSAs, for example).
>>
>>
>> It seems that you are OK with 5.3 (no comments)
>> "Containment of routing information MUST not be compromised to allow=20
>> inter-area traffic
>>    engineering. Information propagation for path-selection=20
>MUST continue
>>    to be localized.".
>> Thus you should also be OK with 7.4
>
>Actually, 5.3 imposes a requirement to preserve IGP hierarchy=20
>and scalability, but at least leaves open the possibility for=20
>the IGP to carry extra information as long as it is not an=20
>"unreasonable amount of extra information" that does not=20
>"unreasonably increase IGP flooding frequency".

Basically 5.3 points out that information propagation for PATH-SELECTION =

MUST continue to be localized.=20
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=20
>unreasonable is, and leave it to the protocol designers to=20
>devise protocols that keep within those limits. Instead it=20
>seems to prescribe a realization -- one where no topology=20
>related info. of any sort should be added to the IGP LSAs.
>
>> Basically we want to preserve IGP hierachy concept, are there=20
>> objections to that point ?
>
>Depends on whether you want to preserve it in spirit or to the=20
>letter :-). I think it may be useful to give protocol=20
>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=20
>> topology related info accross areas". Of course, this does not=20
>> preclude the addition of info to the LSA, provided that it is not=20
>> topology related.
>>
>> >
>> >If solutions can meet the scaling requirements by adding a bit of=20
>> >info. to the IGP, I think this should be allowed, otherwise=20
>there is=20
>> >really not much that could be achieved using current mechanisms=20
>> >(since no modifications to them seem permissible, and we already=20
>> >established that these, as they exist, do not provide for adequate=20
>> >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,=20
>which can=20
>> >supposedly compute optimal paths without any impact on the IGP.
>> >
>> >I think this argument isn't quite complete, since it hides the=20
>> >signaling extensions required for these as well as the scalability=20
>> >impact of recursive PCE-type schemes (btw, this was a question that=20
>> >came up in independent discussions with JP in the context=20
>of the ARO=20
>> >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=20
>each of the=20
>> >N ARBs at the border of the neighboring areas is connected to each=20
>> >other ABR. No? In reality, the number of crankback's may be=20
>> >significantly less therefore.
>>
>> No, basically if you have X1 ABRs in head-end area and X2 ABRs in=20
>> tail-end area you may have up to X1*X2 crankbacks, provided=20
>that there=20
>> is a path between all ABRs. This does not assume direct connectivity=20
>> 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=20
>> >considered "extra-load" in signaling and routing here. Is=20
>that to be=20
>> >interpreted as _absolutely no change_ to current signaling and=20
>> >routing protocol objects?
>>
>> No, this should not be interpreted as "absolutely no change".=20
>> Basically the solution must respect scalability requirements=20
>spelt out=20
>> in 5.2 Will clarify in next revision.
>>
>>
>> >seem feasible, if inter-area routing/TE is to be achieved, so=20
>> >something more specific is implied, which would be good to=20
>spell out.
>> >
>> >BTW, also tend to agree with Adrian's point that this section seems=20
>> >to be describing the computation of diverse paths rather than the=20
>> >establishment of diverse paths, which would seem to be the=20
>> >requirement.
>>
>> Yes this is basically a requirement on computation, but in this=20
>> inter-domain context Path computation and Path establishment are no=20
>> 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=20
>> >traversing multiple areas)?
>>
>> Yes, will reword
>>
>> >
>> >13. Sec. 8.2, not sure that is providing a real measurable=20
>evaluation=20
>> >criterion. If it is to be kept, some specifics should probably be=20
>> >given.
>
>JL, sure. The perf. requirements are given in Sec. 8.1, but I=20
>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 =3D to explanation=20
>for (1) and (2) that you've given below.

OK=20

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

>

Thanks again for these comments. We will post, on Monday, a new revision =
incorporating received comments.

Regards,

JL