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

From: "Pyda Srisuresh" <[email-masked]>
Date: Mon, 16 Dec 2002 12:06:10 -0800

resending... My apologies, if you receive two copies of this.
I believe, the orginal e-mail did reach the ietf list. Thanks.

regards,
suresh
-----Original Message-----
From: Pyda Srisuresh [mailto:[email-masked]]
Sent: Friday, December 13, 2002 11:13 AM
To: [email-masked]
Cc: Pyda Srisuresh; [email-masked]
Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2
to Proposed Standard

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.

Below are my specific comments on the draft.

1. The draft basically describes link TLVs for area-wide
   flooding. OSPF is an AS-wide IGP, not just area-wide.  

   So, I would suggest renaming the draft as "TE extensions
   to an OSPFv2 area", instead of the current title,
   "TE extensions to OSPFV2". 

   Large OSPF networks with multiple areas will not
   run this protocol.

2. It is confusing to refer an opaque LSA with with a 
   specific sub-type as "TE LSA". It makes it sound like a 
   stand-alone OSPF LSA with a distinct LSA type - which 
   is is not. OSPF LSAs define the flooding scope. TE LSA
   does not.
   
   One suggestion would be to refer Opaque LSAs with specific 
   sub-type 1 as "TE-type Opaque LSA".

3. The limitations section (section 1.2) should mention the 
   following limiations with a mixed network containing TE 
   and non-TE nodes. 
      1. When a network area is constituted of TE and 
         native-nodes (supporting IP-only links), the opaque 
         LSAs will flood all nodes in the area, thereby 
         disrupting native OSPF nodes.

	 As As a general rule, a TE network is likely to generate 
         significantly more control traffic than a native OSPF 
         network. The excess traffic is almost directly proportional
         to the rate at which TE circuits are set up and torn down 
         within the TE network. 

         The more frequent and wider the flooding frequency, 
         the larger the number of retransmissions and Acks. 
         It is undesirable to flood non-TE nodes with TE TLVs.

      2. A link cannot be reserved for TE-only use. All links
         must be subjectable to best-effort IP traffic first, 
         before any of the links are permitted to carry TE traffic.
         
         In a mixed network, an OSPF router supporting TE-links 
         and native IP-links could potentially select a TE link 
         to be its least cost link and inundate the link with 
         best-effort IP traffic,  thereby rendering the link 
         unusable for TE purposes.

regards,
suresh

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of The
IESG
Sent: Monday, November 25, 2002 3:47 PM
To: [email-masked]
Subject: Last Call: Traffic Engineering Extensions to OSPF Version 2 to
Proposed Standard

The IESG has received a request from the Open Shortest Path First IGP
Working Group to consider Traffic Engineering Extensions to OSPF
Version 2 <draft-katz-yeung-ospf-traffic-09.txt> as a Proposed
Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by December 26, 2002

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt

---

From: Kireeti Kompella <[email-masked]>
Date: Tue, 17 Dec 2002 15:17:33 -0800 (PST)

Hi,

> The draft is a solution to providing TE within an OSPF area.

Yes.

> non-TE nodes). Please see my comments below.

Actually, inter-area TE is a hard problem -- however, the issue is not
how you format the bits or what type of LSA you use, but what
information should be carried, how it should be summarized (if at all
that is a feasible approach), minimizing crankback, etc.

> I would not

Your recommendation is noted.  Of course, that is not the issue at
hand -- the issue at hand is a proposal for *intra-area* TE.

> document to guide it.

Perhaps you should read RFC 2702 before making comments.

> The vendors and implementors behind the
> and motivations, such as having some working code.

Your point being that working code is a Bad Thing?

>    "TE extensions to OSPFV2".

If you're going to comment on the title, please at least get it right:
it's "Traffic Engineering Extensions to OSPF Version 2".

Your suggested title would be unnecessarily long; anyone who can read
the very short (20 word) abstract will learn that this is for intra-area
TE post haste.

>    Large OSPF networks with multiple areas will not

Crystal ball?  I suggest you get a new one.

>    sub-type 1 as "TE-type Opaque LSA".

This is beyond nitpicking.  Note that the Opaque LSA for Graceful
Restart is called the Grace LSA; also that many many other documents
besides this one call the "TE-type Opaque LSA" simply a TE LSA.

>          It is undesirable to flood non-TE nodes with TE TLVs.

Do you know of any "mixed networks"?

You're right, however, that if non-TE-capable nodes are present in the
network, they will have to flood the LSAs carrying TE information as
well.  However, this is a natural characteristic of OSPF flooding and
Opaque LSA mechanism not changed by the TE extensions, hence does not
need to be explicitly explained.

>          before any of the links are permitted to carry TE traffic.

This is patently false.  There are two methods of "reserving" links
for TE-only use, one of which is documented in "LSP Hierarchy with
Generalized MPLS TE", the other being the obvious 'advertise the link
LSA with infinite SPF metric'.

While I respect your right to comment (that is after all the point
of an IETF Last Call), I would really suggest you do your homework
before you comment.

In summary, I have read and responded to the comments above; in my
opinion, they do not warrant any changes to the document.  However,
if any one else feels otherwise, please do not hesitate to let me
know, and I will reconsider my decision.

Kireeti.

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Wed, 18 Dec 2002 12:50:56 -0800

<... snip>

> that is a feasible approach), minimizing crankback, etc.

You forgot to mention flooding.

> hand -- the issue at hand is a proposal for *intra-area* TE.

You are right. The draft at hand is about intra-area TE.
There are many reasons why I recommend the draft be not 
extended to inter-area and mixed networks. There is often
a tendency to assume extensibility or using the existing 
draft/RFC as the basis for inter-area and mixed networks 
unless stated otherwise. It is also concerning because the
OSPF WG currently has no drafts in its charter to cover 
inter-area and mixed networks. Lastly, this intra-area draft
is bound to impose backward compatibility requirements on 
any follow-on drafts covering inter-area and mixed networks.

Hence, a statement of applicability and limitations is 
warranted in the draft.

> Perhaps you should read RFC 2702 before making comments.

Kireeti - I am aware of RFC 2702 and have reviewed it.
The RFC is about requirements and applications of TE over MPLS.
The RFC is *not* about requirements for the IGP collecting 
TE metrics within an Autonomous System(AS). I was refering 
to the latter.

> Your point being that working code is a Bad Thing?

I am saying that the problem should be well defined, 
before you decide on a solution.

Having "some" working code that solves a problem is not the 
same as having working code that implements a solution to a 
well-defined problem.

> the very short (20 word) abstract will learn that this is for intra-area
Truth in labeling is important; And, I suggested a label that
is truthful and will fit in a line.

The whole crux of my comments has been on scaling and applicability
limitations. 

> Crystal ball?  I suggest you get a new one.

READ - This protocol is restricted in scope to a single area.
I will leave the crystal ball business to the market.

> besides this one call the "TE-type Opaque LSA" simply a TE LSA.

What is the RFC that uses the term "Grace LSA" ?

This is not nitpicking. It is just a matter of using the
terminology right, so it doesnot cause semantics confusion.
I pointed out what the confusion is. Hope  you understand.

> Do you know of any "mixed networks"?
I would reframe the question as - Can you assume there wont be
any mixed networks?

> need to be explicitly explained.

Yes. The draft uses Opaque LSA to propogate TE metrics. 
Naturally, all the limitations of the opaque LSA will limit
the TE extensions.

> LSA with infinite SPF metric'.

OK, let me try this differently.

In the intra-area TE extensions proposal, all IP networks 
(TE and non-TE alike) belong to the same address space and 
are advertised on all links, TE and non-TE alike.

When a node does not have non-TE links (or a non-TE link
went down), IP packets are still forwarded using the shortest
path. I am not aware of a way to notify the router to not
forward IP packets on a TE link. As a result, TE link(s) with 
infinite cost will be used to forward IP packets. When multiple
TE links exist on the same node to reach an IP network, and all
TE-links are configured with infinite SPF metric, the first TE
link will still be used to repeatedly to forward IP traffic.

Hope this explains.

<... snip>

regards,
suresh

---

From: "Mike O'Dell" <[email-masked]>
Date: Wed, 18 Dec 2002 16:47:18 -0500

actually, in the IETF, having running code for *one* solution is a good 
way
to demonstrate how much of the problem is understood, and if some of
us had our way, it would be impossible to charter a Working Group
*without* the understanding of the problem space being *at least* that 
good.

	cheers,
	-mo

"Always do right.  It will gratify some people and astonish the rest."
							-Mark Twain

---

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

I understand.

The flip side to this is that once a solution is 
implemented and deployed, there is lethargy to look at 
other solutions (or) to expand the problem space. Then,
there is the legacy of this implementation that
future solutions have to live with.

Anyways, this is all the more why I believe, the protocol
document should at a minimum cover the boundaries of
its applicability.

regards,
suresh 

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Mike
> O'Dell
> Sent: Wednesday, December 18, 2002 1:47 PM
> To: [email-masked]
> Cc: Mike O'Dell; [email-masked]
> Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
> 
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Dec 2002 18:00:58 -0500

> way to demonstrate how much of the problem is understood, and if some of

problem is, if we raised the barrier to that level, we'd get even more
groups insisting on adopting the "one solution" without significant 
change  - treating it as inviolate rather than as a proof of concept.
we have far too many of those groups already.

Keith

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 18 Dec 2002 15:36:54 -0800 (PST)

On Wed, 18 Dec 2002, Pyda Srisuresh wrote:

...

> Hence, a statement of applicability and limitations is

Let me be more precise: draft-katz-yeung says how TE in a single OSPF
area can be accomplished.  It doesn't aim to address the multi-area
case; *nor does it say that it cannot do so*; *nor should it do so*.
There is work going on to address multi-area TE *that builds on this
draft*.  In spite of your "recommendations", this multi-area work
building on draft-katz-yeung has a lot of traction.  I therefore have
no intentions of putting in incorrect or incomplete limitations.

...

> TE metrics within an Autonomous System(AS). I was refering

draft-katz-yeung is *not* about collecting TE metrics.  It's about
providing a topological database that can be used for routing traffic
trunks; the parameters that are carried in this database are those
whose semantics and applicability are described in RFC 2702.

...

> READ - This protocol is restricted in scope to a single area.

I beg to differ -- see above.

In response to your comments, I will add the following statement
at the end of the second para in the Introduction:

"This document purposely does not say how the mechanisms described
here can be used for traffic engineering across multiple OSPF areas;
that task is left to future documents."

Kireeti.

---

From: "Pyda Srisuresh" <[email-masked]>
Date: Wed, 18 Dec 2002 16:31:15 -0800

> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Wednesday, December 18, 2002 3:37 PM
> To: Pyda Srisuresh
> Cc: [email-masked]; [email-masked]

Kireeti - You apparantly have an attitude and it shows. Outside 
of your attitude, you have not said anything in your defence.

All my comments including those on limitations remain unanswered.

> that task is left to future documents."

This is *not* what I stated in my comments and is *not* 
a characterization of my commnents. 
 
I gave backing for all the comments I made. I am sorry to say
you did little on your part, other than come back with an attitude. 

regards,
suresh

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 18 Dec 2002 17:16:14 -0800 (PST)

> of your attitude, you have not said anything in your defence.

You clearly have an agenda.  Those who have a background in this
matter know this.  Those who don't don't know how lucky they are.

Let me repeat, using short words with few syllables:

1) draft-katz-yeung says how to do TE in a single OSPF area.
2) draft-katz-yeung does not address the multi-area case.
3) Given (2), it does not make sense to put in lim it ations that
   say it won't work in the multi-area case when at worst we don't
   know, and at best it may in fact work like a charm.

> All my comments including those on limitations remain unanswered.

You confuse "answered, but not to your satisfaction" with "unanswered".

...

> a characterization of my commnents.

I never said that that's what you stated.  I just said that that was
what I would insert.

It's been fun,
Kireeti.

---

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

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kireeti Kompella
> Sent: Wednesday, December 18, 2002 5:16 PM
> To: Pyda Srisuresh

There is no secret or hidden agenda here. Stop making 
insinuations.

It is no secret that I have a competing draft, titled,
"OSPF-TE: An experimental extension to OSPF for Traffic 
Engineering" (filed as draft-srisuesh-ospf-te-04.txt). 
I sent messages in the past to the OSPF WG, comparing my 
draft to the katz-yeung draft. This is what Rohit Dube was
alluding to in his last e-mail.

Make no mistake. The comments I sent to the IETF were solely 
in response to the IETF last call on the katz-yeung draft; not
in comparison with any specific draft. I mentioned this to Rohit
in my last e-mail to him. It is part of the IETF process to let 
the wider community know of the concerns with the draft. I am 
doing my share. I backed all my comments with explanations.

>    know, and at best it may in fact work like a charm.

No dispute here. My comment in this context was to fix the title.

My remaining comments are to do with fixing confusing terminology 
and adding limitations of the model vis-a-vis mixed networks.

> You confuse "answered, but not to your satisfaction" with "unanswered".
Your answers were either incomplete or riddled with attitude so
as to sidestep the original comment.

<... snip>

regards,
suresh