[Top] [All Lists]

RE: Last Call: Traffic Engineering Extensions to OSPF Version 2 to Proposed Standard

2002-12-17 14:17:45

My comments were made solely in reference to the
draft-katz-yeung draft; not in comparison to any specific draft,
as you might believe.

As for the comment from John Moy (circa July 2001) about the
availability of an inter-area OSPF draft, I do recall responding
that the inter-area draft was assuming additive properties to
TE metrics to advertise summary info. It is a mistake to assume
that all TE metrics can be additive.  Below is a pointer to
the response I sent.;

This goes right back to the comment I made below about
using the draft-katz-yeung draft as the basis for inter-area TE.


-----Original Message-----
From: Rohit Dube [mailto:rohit(_at_)xebeo(_dot_)com]
Sent: Tuesday, December 17, 2002 11:46 AM
To: srisuresh(_at_)yahoo(_dot_)com
Cc: ietf(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org; 
fenner(_at_)research(_dot_)att(_dot_)com; acee(_at_)redback(_dot_)com
Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2
to Proposed Standard


You have brought up this issue on the ospf mailing list a couple
of times and as such the topic has been addressed on the list.

Here is pointer to an email from John Moy (circa July 2001)
and another more recent one from me in response to your email on your
alternate-te proposal

(OSPF WG co-chair)

::The draft is a solution to providing TE within an OSPF area.
::The draft has serious scalability limitations in
::extending this to inter-area and mixed networks (with TE and
::non-TE nodes). Please see my comments below. I would not
::recommend using this draft as the basis for building further
::TE-extensions to inter-area and mixed networks.
::The draft apparently evolved over time with no requirements
::document to guide it. The vendors and implementors behind the
::draft may have been guided by different set of requirements
::and motivations, such as having some working code. Unfortunately,
::this ad-hoc approach has a cost. Any new requirements are having
::to be met in a reactive mode and having to be provided as fixes
::on top of this "working" code. This is not right and doesnt bode
::well for the future of the protocol.

<Prev in Thread] Current Thread [Next in Thread>