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

From: "Pyda Srisuresh" <[email-masked]>
Date: Tue, 17 Dec 2002 13:11:37 -0800

Rohit,

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.
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&T=0&F=&S=&
P=5937

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

regards,
suresh

-----Original Message-----
From: Rohit Dube [mailto:[email-masked]]
Sent: Tuesday, December 17, 2002 11:46 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2
to Proposed Standard

Suresh,

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)
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0107&L=OSPF&D=0&I=-3&P
=15162
and another more recent one from me in response to your email on your
alternate-te proposal
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0212&L=OSPF&D=0&I=-3&P
=6031

Best,
--rohit.
(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.
[snip]

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 17 Dec 2002 13:32:34 -0800

Suresh,

> http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&T=0&F=&S=&

Please look at draft-kompella-mpls-multiarea-te-03.txt, as
at least some of the approaches described in that draft
do *not* assume additive properties of TE metrics (and do not
advertise summary info).

Yakov.

---

From: Rohit Dube <[email-masked]>
Date: Tue, 17 Dec 2002 14:45:41 -0500

Suresh,

Here is pointer to an email from John Moy (circa July 2001)
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0107&L=OSPF&D=0&I=-3&P=15162
and another more recent one from me in response to your email on your 
alternate-te proposal
http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0212&L=OSPF&D=0&I=-3&P=6031

Best,
--rohit.
(OSPF WG co-chair)

---

From: Rohit Dube <[email-masked]>
Date: Tue, 17 Dec 2002 16:22:48 -0500

On Tue, 17 Dec 2002 13:11:37 -0800 "Pyda Srisuresh" writes:
=>Rohit,
=>
=>My comments were made solely in reference to the
=>draft-katz-yeung draft; not in comparison to any specific draft,
=>as you might believe.
[snip]

Suresh,

This is not the first time we are hearing from you on the topic. Your
original mail to [email-masked] does not mention any context or previous
discussion on the topic when such a context exists.

I simply wanted to make people not on the ospf list aware of this.

--rohit.

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Wed, 18 Dec 2002 20:30:21 -0800

<... snip>

> do *not* assume additive properties of TE metrics (and do not

Yakov - You are right. The draft does talk about different 
mechanisms the MPLS signaling protocols could use to setup
LSPs in an AS spanning multiple areas. However, the draft is 
not about inter-area OSPF TE.

Clearly, there is interplay between signalling protocols and
the extent of TE link state data base (TE-LSDB) a node has.
I believe, scenario-3 is where the inter-area OSPF-TE is in 
place and all nodes in an area have the same information as
their ABRs do. This scenario presents the signalling protocols
with fast convergence in settign up an LSP, right.

regards,
suresh

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 19 Dec 2002 08:27:18 -0800

Suresh,

> > > http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0108&L=ospf&
> > >T=0&F=&S=&P=5937
> > 

The draft is about multi-area TE, as it describes how to solve
the problem of supporting TE in a multi-area environment.
  
> with fast convergence in settign up an LSP, right.

Just to point out that quite a few scenarios described in
draft-kompella-mpls-multiarea-te-03.txt are supported with the TE
extensions that are subject to this Last Call. To repeat what
Kireeti said already "There is work going on to address multi-area
TE *that builds on this draft*."

Yakov.

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Thu, 19 Dec 2002 10:33:35 -0800

<... snip>

> the problem of supporting TE in a multi-area environment.
OK.

> TE *that builds on this draft*."

Yakov - My comment on the katz-yeung draft concerning multi-area
is that it supports TE in a single OSPF area; and hence to rename
the draft as "TE extensions to an OSPFv2 area". 

My recommendation against using this draft as the basis for 
building further TE-extensions to inter-area and mixed networks
was in the context of OSPF Autonomous System (AS). I also 
mentioned the draft has scalability limitations in extending this 
to inter-area and mixed networks -  also in the context of OSPF AS.

Without going into the details of the "Multi-area MPLS Traffic
Enginering" draft - The work cited in this draft as going on to 
address multi-area TE is in the MPLS signalling context, not in 
the OSPF.

regards,
suresh

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 19 Dec 2002 10:47:00 -0800

Suresh,

> the draft as "TE extensions to an OSPFv2 area". 

Let's be precise. The katz-yeung draft defines certain TE-related
information, and specifies how to distribute this information within
a single area. That is it.

> address multi-area TE is in the MPLS signalling context, not in 

As I said in my previous e-mail quite a few scenarios described in
draft-kompella-mpls-multiarea-te-03.txt are supported with the TE
extensions that are subject to this Last Call. That is precisely
while quite a few scenarios in the "Multi-area MPLS Traffic Engineering" 
draft do not require any additions to what is already defined
in the katz-yeung draft. 

Yakov.

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Sat, 21 Dec 2002 07:39:50 -0800

<... snip>

> draft do not require any additions to what is already defined

Yakov,

Yes, quite a few scenarios described in kompella-mpls-multiarea-te draft 
are supported with single-area TE extensions and do not require any 
additions. And, katz-yeung draft proposal will suffice for single-area 
TE extensions. 

katz-yeung draft does not cover dissemination of inter-area TE info
(which I was refering to as *inter-area OSPF-TE*). Neither does the 
draft claim to do so. Inter-area OSPF-TE is a scenario described in 
kompella-mpls-multiarea-te for faster convergence in LSP computation.

In this context - my recommendation to not use katz-yeung draft as the 
basis to extend to inter-area OSPF-TE was because of its scaling 
limitation.

Neither katz-yeung nor kompella-mpls-multiarea-te drafts address mixed
networks. katz-yeung draft has limitations with flooding disruption 
and topology isolation in a mixed network - both intra-area and 
inter-area. This was another reason why I recommended to not use 
katz-yeung draft as the basis to extend to inter-area OSPF-TE.

regards,
suresh

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 22 Dec 2002 06:28:50 -0800

Suresh,

> additions. And, katz-yeung draft proposal will suffice for single-area 

Good. So we are in agreement that the katz-yeung draft can support
both single area and multi-area TE.

> draft claim to do so. 

That is correct too. 

> Inter-area OSPF-TE is a scenario described in 

I am not sure which scenario you are referring to. But anyway, this
is outside the scope of the present discussion...
  
> basis to extend to inter-area OSPF-TE was because of its scaling 

And my recommendation is exactly the opposite - start multi-area TE
with what is already in the katz-yeung draft, gain some operational
experience with it, and then improve this, *if necessary*, based on 
the experience. But anyway, this is outside the scope of the present
discussion...
  
> katz-yeung draft as the basis to extend to inter-area OSPF-TE.

To avoid any confusion I would suggest to add the following to
the katz-yeung draft:

  It is an explicit non-goal of the solution described in this
  document to address all possible (as well as impossible)
  requirements. Therefore, the solution described in this document
  is clearly not a perfect solution, and as such doesn't quality
  for being a LTSFGTC (Long Term Solution For Generations To Come).
  Work on the perfect solution (aka LTSFGTC) is in progress, and is
  expected to be published in RFC100000.

Yakov.

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Sun, 22 Dec 2002 18:39:35 -0800

Yakov,

Are you saying inter-area OSPF TE is not required?

Without the inter-area OSPF TE, the non-backbone areas of an
OPPF AS boil down to being *stub areas* and the backbone area
becomes the only area. The round-robin ABR based trial-and-error
CSPF computations can take inordinate amounts of time for LSP convergence.
As LSPs are setup, TE network reachability changes.
Without the inter-area OSPF TE, nodes are blind to TE reachability outside
the area. Not offering inter-area OSPF TE, I believe, is
a disservice to customers who need predictability. Same goes with
the flooding and other limitations imposed on mixed networks.

Lack of a requirements document for OSPF TE is clearly the cause
of this debate. It may not be too late to work on one.
Borrowing Keith's words, it sounds like we have a group of people insisting
on adopting the "one solution" without significant
change - treating it as inviolate rather than as a proof of
concept.

regards,
suresh

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Sunday, December 22, 2002 6:29 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
>
>
> Suresh,
>