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

Fwd: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt

Hi,

X-BrightmailFiltered: true
Subject: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
Date: Thu, 27 May 2004 15:26:11 +0200
Thread-Topic: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
Thread-Index: AcRDYVXKfrB8O1zuT9C+EBARnFFdEQAiduDg
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@francetelecom.com>
To: "Tony Li" <tony.li@tony.li>, "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <te-wg@ops.ietf.org>, <ccamp@ops.ietf.org>
X-OriginalArrivalTime: 27 May 2004 13:26:19.0661 (UTC) FILETIME=[3231ABD0:01C443EE]
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=2.63
Sender: owner-ccamp@ops.ietf.org
X-PMX-Version: 4.6.0.99824
X-from-outside-Cisco: 128.107.250.143

Hi Tony

Please see inline

Regards

JL

>-----Message d'origine-----
>De : Tony Li [mailto:tony.li@tony.li]
>Envoyé : mercredi 26 mai 2004 22:37
>À : Adrian Farrel
>Cc : LE ROUX Jean-Louis FTRD/DAC/LAN; te-wg@ops.ietf.org;
>ccamp@ops.ietf.org
>Objet : Re: Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt
>
>
>> I accept that full leakage of all TE information in a dynamic way
>> would almost certainly
>> have a major impact on IGP scalbility.
>>
>> I do not accept that some carefully considered leaking of aggregated
>> TE information on a
>> sparse timer basis would necessarily have such a dire impact.
>>
>> This is why I want the requirements draft to tell me what impact on
>> the IGP I am allowed
>> to have and leave CCAMP to derive a solution that fits that
>> requirement. I don't think it
>> is right to tell CCAMP what solutions it may or may not consider.
>>
>
>
>Operator hat on:
>
>I would very much like to see it be a requirement that no information
>is leaked
>without specific configuration.  Further, I would very much like to see
>implementations give us reasonable granularity (and reasonable
>abstraction) in
>what we choose to leak.
>
>As an example, I would like to be able to leak detailed topology
>information from
>my IS-IS L2 database down into an L1 area.  I would NOT want to leak
>bandwidth
>information.

I don't see the gain, as regards inter-area TE,
in leaking detailed topology information from L2 into L1 without leaking any bandwidth information...

Bandwidth + any other TE -related info, which would in turn mean to have a single area.

JP.

>I would want to leak an abstraction of another L1 area
>down into an
>L1 area, but I would definitely want that to be an
>abstraction, NOT the
>full
>database.

Of course, else you come back to a single area network !
But IMHO such abstraction, to be useful, i.e. to allow computing an inter-area TE path,
would require to take into account a large set of constraint combinations,
and this would likely lead to major impact on IGP scalability.


Agree also ... Moreover, as the set of constraints get larger, the IGP impact will also increase.

>
>I am not interested in perfect optimality.  I am interested in
>what can
>be
>achieved with a limited amount of overhead.  It is very clear that
>there cannot be
>any improvements without some impact on IGP scalability.

Not so sure, there are schemes that allow computing an optimal inter-area path without adding any byte in LSA/LSP...

>If nothing
>else, every
>byte in an LSA/LSP counts towards router memory consumption.  Thus, we
>have a
>tradeoff that we need to make and perfect optimality is not a
>reasonable goal in
>light of limited scalability.  Good returns can be had by leaking
>information
>that is topologically "close by" and abstracting distant information.

See above comments on TE abstraction

>If

>necessary, this can be supplemented by path manipulation along the way.
>
>Regards,
>Tony
>
>