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

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

hi jean-louis

thanks for the clarifications; see in-line for some hints

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

Hi Dimitri,

Thanks a lot for these comments. See additional comments on top of JP
comments.

Cheers

JL


-----Message d'origine----- De : Jean Philippe Vasseur
[mailto:jvasseur@cisco.com] Envoyé : mardi 30 mars 2004 14:36 À :
Dimitri.Papadimitriou@alcatel.be Cc : LE ROUX Jean-Louis
FTRD/DAC/LAN; ccamp@ops.ietf.org; mpls@UU.NET Objet : Re: TR : I-D
 ACTION:draft-ietf-tewg-interarea-mpls-te-req-00.txt


Hi Dimitri,

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,


Basically the solution must preserve IGP hierarchy, and thus must
preclude leaking of any TOPOLOGY related information accross areas,
including TE link information such as carried in ISIS Extended IS
reacheability TLV, or OSPF TE LSA Link TLV. Note that this also
precludes leaking of any summarized/aggregated TE information, such
that the advertisement of maximum unreserved bandwdith between an ABR
and any end-point LSR. We will clarify that in next revision.


this would refine the above requirement (such TE link information
would be precluded in any of its form)

In return we definitely not preclude leaking of NON TOPOLOGY related
information such as TE node capabilities, provided that IGP
scalability is not impacted.


more than probably, it is not within this kind of document to
provide a kind of classification of such information but the
latter would help in detailing the "discovery" concepts (see
also section 7.12) in terms of functionality that would be
required here: identity, capability & associated capability

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

c-igp-02.t

xt>

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



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. 


I see your point here. Basically there are two possible approaches
for LSP configuation -Option 1: Configure only the desired level of
optimality: Optimal, sub-optimal, then the head-end choose the
corresponding path computation approach. -Option 2: Configure
directly the desired path computation method: e.g. ERO expansion or
PCE computation

Option 1 is IMHO too generic, and a Service Provider wants to have
direct control on the selection of the path computation method.

We will clarify that in next revision

ok

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"


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.


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


Actually this section is not dedicated to crankback routing as a path
computation method,  it only addresses possible use of crankback in
case of network failure. Thus we refer here only to the recovery
delay. We may add a section dedicated to crankback routing in the
next revision

i would agree to have a requirement document that includes a dedicated section on crankback functionality, hope the next release will clarify

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



Yes you are right, both sections refer to lsp recovery Basically
section 7.7 deals with LSP rerouting and section 7.8 is dedicated to
Fast Reroute protection We will update as follows 7.7 LSP recovery 7.7.1 LSP rerouting 7.7.2 Fast Reroute

ok

6) section 7.11

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

ok



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.

thanks for your comments !

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

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