[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt

hi jp,

see in-line:

Thanks for your useful comments here. See below,

At 02:18 PM 3/30/2004 +0200, Dimitri.Papadimitriou@alcatel.be wrote:

hi jl, here below several comments on this updated version of the document:

1) section 5.3.1 mentions:

"The solution MUST entirely preserve the concept of IGP hierarchy. In
   other words, flooding of TE link information across areas MUST be
   precluded."

section 5.3.2 mentions:

"The solution MUST also not increase IGP load which could compromise
   IGP scalability. In particular, a solution satisfying those
   requirements MUST not require for the IGP to carry some unreasonable
   amount of extra information and MUST not unreasonably increase the
   IGP flooding frequency."

but section 7.12 tells:

"The discovery mechanism SHOULD
   be applicable across multiple IGP areas, and SHOULD not impact the
   IGP scalability, provided that IGP extensions are used for such a
   discovery mechanism."

-> would it be possible to align these requirements, i get the impression (please confirm) that you preclude TE link information but you would allow for node information (auto-mesh) ? note also that the section 7.12 doesn't tell us a lot about the expected distribution of the mesh


The solution MUST preclude to flood TE-related link information and MUST not compromise the IGP scalability in any circumstances. That being said, IGP based mechanisms can be used for the discovery which will respect the requirement mentioned above, 

i understand to what you're referring, but please make it clear
imho it would help if in section 7.12 the exact meaning of the
following "*some* discovery mechanisms" was detailed so that the
reader can more accurately assess the scope of the above

2) section 7.3

"   In the context of this requirement document, an optimal path is
   defined as the shortest path across multiple areas taking into
   account either the IGP or TE metric. "

are you referring here to
<http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-02.txt>


would you clarify ?


Sure, we will add some text. The reason for this clarification is that there are a multitude of definitions for an optimal path: paths that minimize the max link utilization, call set up failure, ... here we just refer to the ability to compute a shortest path (using either the IGP or TE metric).

ok

3) section 7.3

it is not clear for me what is behind the last part of the following sentence

"So a solution should support both mechanisms, and SHOULD allow
   the operator to select by configuration, and on a per-LSP basis, the
   required level of optimality. "

what is meant by "level of optimality" ? is it simply "optimal - sub-optimal" or do you have something else in mind ?


We will clarify. The idea is that the ability to compute an end to end shortest path may not be required for all inter-area TE LSPs. Hence the solution should allow the operator to select the appropriate path computation method.

ok, would be interesting to see whether operators would like to have selection based on the computational method (allow for intermediate computation or any other option suitable in this context) or based on the optimality level (then the solution itself selects the appropriate computational method) or simply both

4) section 7.4

"Another example is the requirement to set up multiple TE LSPs between
   a pair of LSRs residing in different IGP areas in case a single TE
   LSP satisfying the set of requirements could not be found. "

why in such a case diversity would be desirable ?


for either path protection or load balancing while minimizing the impact in case of failure.

got the impression that if a single path would have been feasible it would have been selected in this case - isn't it ?


That being said, we need to rephrase, I agree with you that this paragraph is not clear. It should read:

"Another example is the requirement to set up multiple TE LSPs between a pair of LSRs residing in different IGP areas. For instance, this would occur if TE LSP satisfying for instance the bandwidth requirement could be found, hence, requiring to set up multiple TE LSPs"

the former point(s) seem clearer, is it "could be found" or "could not be found" ?

5) section 7.7

"This may reduce the recovery delay, but with the risk of
   multiple crankbacks, and sub-optimality.  "

i agree, but this is valid iff the head-end has initially computed an end-to-end optimal path,


more exactly this applies to contiguous LSP. For sub-optimality this applies to any kind of LSP. 

well i think that a contiguous LSP can still be sub-optimal hence
i would suggest to not implicitly attach the crankback functionality
to the signaling method, but to make clear what are the potential
issues in terms of optimality as said "iff the path was initially
computed as an end-to-end optimal"

also unclear if you refer also here to the provisioning delay ?

editorially speaking it is also a bit unclear why you've splitted section 7.7 and section 7.8 both refers to inter-area lsp recovery 

i don't know if this could be taken into account, this would simplify
reading and subsequent utilisation of the document

6) section 7.11

would it be possible to mention what's expected (or not expected) in terms also of hard preemption ?


ok

just a hint here, is my understanding correct that the following sentence "The lower priority LSP is not torn down and can continue to forward traffic on a best-effort basis." infers that you would have to priority high/low only so i'd would instead be more generic here in
terms of priorities

7) section 8.2

what's meant by stability ? ie stability of what ? (for instance, as i read the document, but please correct me, stability and re-optimization are imho two features that are going in somehow opposite directions so a trade-off has to be found here)


We will clarify.

ok

thanks for your comments !

hope to see the next version soon, would also be interesting to see other people commenting here

thanks,
- dimitri.

JP.

thanks in advance,
- dimitri.

LE ROUX Jean-Louis FTRD/DAC/LAN wrote:

Hi all,
Thanks in advance for your comments on this new revision of inter-area
TE requirements.
Regards,
JL

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Traffic Engineering Working Group of the IETF.

Title : Requirements for Inter-area MPLS Traffic

Engineering

       Author(s)       : J. Le Roux, et al.
       Filename        : draft-ietf-tewg-interarea-mpls-te-req-00.txt
       Pages           : 20
       Date            : 2004-3-26

This document lists a detailed set of functional requirements for the
support of inter-area MPLS Traffic Engineering (inter-area MPLS TE) which could serve as a guideline to develop the required set of protocol extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tewg-interarea-mpls-te-r

eq-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then
"get draft-ietf-tewg-interarea-mpls-te-req-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 



--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491




--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
E-mail : dpapadimitriou@psg.com
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491