RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt
LE ROUX Jean-Louis FTRD/DAC/LAN <jeanlouis.leroux <at> francetelecom.com>
2004-06-11 16:30:16 GMT
Hi Vishal,
Thanks a lot for these highly useful comments.
Please see inline for some answers.
Regards,
JL
>-----Message d'origine-----
>De : Vishal Sharma [mailto:v.sharma <at> ieee.org]
>Envoyé : jeudi 10 juin 2004 03:16
>À : LE ROUX Jean-Louis FTRD/DAC/LAN; TE; CCAMP
>Objet : Last call comments:
>draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>Hi Jean-Louis et al,
>
>I have reviewed the above draft quite carefully, and it is
>a very useful document. Nice work!
>
>There are several comments I have as part of last call, I'm
>giving these below as technical and editorial, to make
>discussion easier.
>
>Thanks,
>-Vishal
>********************************************************************8
>
>Technical
>-----------
>
>1. Sec. 1, Introduction.
>"The set of MPLS traffic engineering tools," is probably
>better worded as "The set of MPLs traffic engineering
>components," as the phrase "MPLS traffic engineering tools" is
>liable to be confused with planning and traffic engineering
>tools/software (a la Netscope, NPAT, SPGuru, MATE, etc.).
Agree
>
>2. In the same section, how are the components useful for
>aggregated traffic measurement? Is it because, OSPF-TE and
>IS-IS TE may be used to convey parameters like aggregate link
>utilization? What else is included here?
Basically TE-LSPs offer an easy mean to measure the traffic matrix.
By accounting packets forwared into a TE-LSP you can deduce the traffic rate
between two end-points.
Some ISPs use a mesh of TE-LSP as a simple way to measure trafic matrix
>
>3. It would be good to have terms like "traffic engineering
>components", "traffic engineering mechanisms" and "traffic
>engineering tools" defined in the terminology section to clear
>distinguish between them, and avoid confusion when reading and
>interpreting this document.
Agree, will be done in next revision.
As suggested by Adrian, we will also add a section summarizing MPLS-TE components (routing, path
computation, signaling).
This will help explaining current limitations and inter-area requirements.
>
>4. Sec. 4.1.3, para 1, not sure what "traffic sensitive
>applications" means. It might be better worded as "performance
>sensitive applications" or "quality sensitive applications."
Agree, "quality sensitive application" is better
>
>5. Sec. 4.2, option 3, it would be nice to have a phrase
>explaining why this is different than LSP hierarchy.
>
OK, will add a phrase to clarify: Basically here there is no FA-LSP advertisement
>6. Sec. 6, para 4, "pseudo wire connections" should really be
>just "pseudo wires"
OK
>
>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.
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.
>
>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.
>
>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
Basically we want to preserve IGP hierachy concept, are there objections to that point ?
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
>
>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.
>
>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.
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.
>
>
>Editorial
>-----------
>
>Below phrases between _xxxx_ are added, and between <xxxx> are
>to be removed.
>
>1. Sec. 1, Introduction, ", that supports ..." --> "which supports ..."
>
>2. Sec. 4, para 1, line 4, "This section is intended to help
>_in_ defining ..."
>
>3. Sec. 4.1.1 --> "Intra-area _resource_ optimization"
>
>4. Sec, 4.1.1. line 1 --> "MPLS-TE can be used within an area
>to redirect paths of aggregated flows away from over-utilized
>resources within a network."
>
>5. Sec. 4.1.1., para 2 -->
>"In this way, MPLS-TE allows for greater control _over_ how
>traffic demands _are routed over_ <utilize> a network
>topology, and _utilize a network's resources_"
>
>5. Sec. 4.1.1., para 2 --> "As mentioned in Section 1, uses
> to date have been limited to <within> a single IGP area."
>
>6. Sec. 4.2, option 4, what are the numbers (2) and (3) in brackets?
>
>7. Sec. 5.1, para 6, "one possible approach could consist _of_
>deploying ..."
>
>8. Sec. 5.2, I am not sure why there is a small subsection
>itself titled "Requirements for inter-area MPLS TE", when the
>entire document is about this subject? Is the intent here to
>motivate the need for inter-area MPLS TE? If so, maybe it
>should say "Motivations for inter-area MPLS TE"?
Thanks a lot for these editorial comments
>
>These a few of the ones that I caught. In general, I feel the
>document would benefit from a thorough editorial review of
>writing, that would help to eliminate some awkward
>constructions and redudancy in several places.
>
>
Agree, will do that for next revision.
Again thanks a lot Vishal, for these highly relevant comments
Regards,
JL
. > > > > > >Hey, I'm with you -- the scenarios are ordered roughly by preference > > > > this was not the intention in the draft though
> So it seems quite relevant to have the ability to signal the desired method.
It would really help to give an example where not being able to control the method would
break the ability to provide the requested service.
(Hint: I think I found one while looking at inter-domain protection paths. But that is a
fairly extreme situation.)
I have serious concerns that allowing this approach means that we risk inter-operability
disconnects.
> 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 don't think holding the FRR draft up as a shining example is particularly wise.
Given that two solutions were included in the document (because the authors/WG could not
agree on a single solution?) and given that those solutions impacted the service provided
to the service requester it was necessary to allow the requester to control the solution.
In this case, controling the solution is equivalent to controling the service.
Note that this feature raises interoperability questions for FRR-enabled networks.
If, as I say, you are able to demonstrate that the inter-domain solutions impact the
service, then you may be on to something.
>>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
Or conversely? 
RSS Feed