[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
- To: LE ROUX Jean-Louis FTRD/DAC/LAN <jeanlouis.leroux@rd.francetelecom.com>
- Subject: Re: TR : I-D ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt
- From: Dimitri.Papadimitriou@alcatel.be
- Date: Tue, 30 Mar 2004 14:18:21 +0200
- Cc: ccamp@ops.ietf.org, mpls@UU.NET
- In-reply-to: <B7D1592DFC5137478D0385A9595C4553F6528D@lanmhs30.rd.francetelecom.fr>
- References: <B7D1592DFC5137478D0385A9595C4553F6528D@lanmhs30.rd.francetelecom.fr>
- User-agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
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
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 ?
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 ?
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 ? got the impression
that if a single path would have been feasible it would have been
selected in this case - isn't it ?
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, 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
6) section 7.11
would it be possible to mention what's expected (or not expected) in
terms also of hard preemption ?
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)
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