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

[Arthi Ayyangar <arthi@juniper.net>]

Hi JL,

Some comments inline.

<snipped>
> ><snip>
> >
> >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.
----------> Let me try to explain this, if possible with a couple of
examples:
Re-optimization
---------------
Actually, nothing prevents you from having Head-end Control of
re-optimzation even with the non-contiguous signaling methods. It is just
that with the non-contiguous signaling methods, one can, if desired, also
have the ability to do a local re-optimization. But if you do not want
this 'intermediate re-optimization' behavior for certain LSPs, you may
want to signal that explicitly or configure it on the box.

Crankback/Re-routing
---------------------
The crankback document actually provides a similar ability for
controlling re-routing at intermediate nodes by signaling this
explicitly.

So, I think that it is basically upto the solutions documents to
address these functionalities. In fact, Dimitri had a very good
example of how by restricting the 'signaling method' you could
shoot down one set of benefits for the other.

thanks,
-arthi

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