Suresh-

I think that in order to replace draft-katz-yeung-ospf-traffic-05.txt,
a document that has already undergone Working Group last call
*and* has been implemented and deployed, your document
(draft-srisuresh-ospf-te-01.txt) would have to be significantly better.
And I think that is not the case.

Inter-area TE metrics can be added on top of
draft-katz-yeung-ospf-traffic-05.txt
as separate Opaque-LSAs. In fact, this has already been proposed in
draft-venkatachalam-ospf-traffic-01.txt.

And I would guess that the other benefit, being able to restrict the TE
information to only participating routers, wouldn't be of that much interest
to the people actually deploying traffic engineering, as it is an
optimization
that only shows up during the transition to a traffic engineered network,
and one
that has a permanent cost in complexity.

John

-----Original Message-----
From: Pyda Srisuresh [mailto:srisureshYAHOO.COM]
Sent: Friday, July 27, 2001 4:27 PM
To: OSPFDISCUSS.MICROSOFT.COM
Subject: Re: I-D ACTION:draft-srisuresh-ospf-te-01.txt

--- Kireeti Kompella <kireetiJUNIPER.NET> wrote:
> Hi Suresh,
>
> > Listed below is a OSPF-TE draft that suggests using new TE LSAs
> > instead of using opaque LSAs to add TE extensiosn to OSPF.
>
> You know my opinions; let me reiterate for the benefit of the OSPF
> group.
>
> > * overcome the scaling limitations of the Opaque-LSA
> > approach for use with heirarchical area topology.
>
> It's not clear to me how the new scheme accomplishes this.
>

Have you had a chance to look at sections 7.3 (TE-sumamry LSAs) and
section 11.3 (Scalability across a hierarchical area topology)?
The TE-summary LSAs provide area-level abstraction to external areas,
without flooding the whole AS.

> > * Flooding of TE LSAs is restricted from effecting non-TE nodes.
>
> That's already the case: non-TE nodes can completely ignore opaque LSAs.
>
That is not the same. The non-TE nodes are forced to receive the opaque
LSAs and ACK them, even if they ignore and do not propogate further.
This can be a considerable interruption to non-TE nodes in a network
that is constituted of multiple TE and non-TE nodes and the TE circuit
paths are constantly in flux (ex: a large network where the TE nodes match
or outweigh the non-TE nodes)
(Section 11.1 describes this in detail).

> > * There is a clean separation between native OSPF LSDB and
> > TE LSDB for use by OSPF routing and MPLS LSP setup
respectively.
>
> That separation exists today: router LSAs vs. opaque LSAs.
>
You are right about the separation. But, Opaque LSA database by itself
is not complete or sufficient to build the TE topology. The Opaque LSDB
needs to refer the native OSPF LSDB to build the TE topology. Even with
that, the opaque LSDB does not reflect TE capabilities of routers.

The TE-LSDB on the other hand is complete in itself to build the TE
topology. This is significant because, the TE-LSDB can be uploaded
to an external host (wiht lots of MIPS) as is, and a traffic
engineering criteria (CSPF) may be applied against this database to
find a TE circuit path meeting a specific TE criteria.

> > * TE LSAs provide a unified extension mechanism for packet and
> > non-packet networks alike.
>
> You should read the GMPLS OSPF draft. It does exactly that.
>
That is the whole point. There wont be a need to have 2 drafts to
accomplish the same. The basic TE extension framework is covered in a
single document.

The GMPLS drafts can simply focus on TLVs specific to non-packet
technologies - not the OSPF-TE itself.

> > I understand, <draft-katz-yeung-ospf-traffic-05.txt> went through
> > WG last call a couple of moths ago in April. We did not have our
> > draft available at that time.
>
> Your draft was needed 3 years ago. A very serious consideration is

I understand. But, let us hope we wouldnt have the same situation repeated
3 years from now. Everything evolves. OSPFv2 and BGP4 didnt happen at the
first try. It would be a mistake to throw baby with the bath water because
it is 3 years late. Hope you understand.

> that the current TE scheme, flawed as it is, has been implemented by
> several vendors, including many routing software providers; has gone
> through innumberable interoperability tests, and is the basis for
> the GMPLS work. Any new scheme on this front would have to have
> significant benefits to warrant uprooting all this.
>
I wonder, if there are interoperable tests and deployments of the
opaque-LSA based TE extensions operating satisfactorily in
(a) multi-area networks, (b) Bandwidth-brokered-LSP based TE networks,
and (c) TE (packet or non-packet) and non-TE mixed networks.

The Opaque-LSA approach has problems related to scalability and
flooding reach in each of the above cases. SLA enforcement on a TE
network is at best a challenge when using opaque LSAs.

In my mind, these are significant benefits. Would you agree?

> Kireeti.

Thanks. Have a nice day.

regards,
suresh

__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]