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

2003-01-07 Thread Alex Zinin


Let me try to summarize this discussion.

Part of the discussion was on draft-katz-yeung vs
draft-srisuesh-ospf-te. Based on the following note from Suresh--

  > 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 will ignore the arguments related to this comparison.

Further comments in this e-mail are based on the text of Suresh'es
original message to the IESG:


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

This does not seem to be an argumentive statement. In fact, the draft
is supposed to do exactly this. Nothing's wrong here.

> The draft has serious scalability limitations in
> extending this to inter-area and mixed networks (with TE and
> non-TE nodes).

Because a) inter-area TE is a non-goal for this draft, and b) the
inter-area TE topic is still in the exploration stage, the draft is
not required (nor should it be assumed) to deal with inter-area TE
scenarios. Hence, I do not believe that inter-area TE properties
should be considered when deciding whether the draft should be
published as an RFC or not.

Kireeti suggested adding the following text to further clarify the
scope of the document:

  "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."

Which I think is a fine idea.
  
Wrt the mixed network scenarios, there doesn't appear to be consensus
that behavior of the mechanism that the WG came up with and described
in draft-katz-yueng is incorrect or dangerous for the network. On the
contrary, my knowledge of the deployment experience suggests that the
mechanism is adequate.

> 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.

Design of the mechanisms for TE in inter-area scenarios is work in
progress and subject to the IETF consensus rules. Suresh is welcome to
participate in this process.

> 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.

As Kireeti mentioned, RFC2702 describes some requirements for MPLS TE.
Suresh argued though that it does not describe the requirements for
the IGP extensions that would satisfy the MPLS TE requirements. I
would like to note, however, that this document has been in the WG for
a very long time, passed the WG last call, and there is a consensus
that the described mechanism is adequate for the intra-area TE task.

> 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". 

As Kireeti replied, the abstract already spells this out. Though I do
not believe this is a must, spelling this out in the title would also
be fine. I'd leave this up to the authors of the document.

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

See above for the multi-area related discussion.

> 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".

I believe that this is a question of editorial preferences.
Changing this terminology wouldn't substantially increase
clarity or readability of the document. Leaving this up to
the authors.

> 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

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

2002-12-22 Thread Pyda Srisuresh
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

> -Original Message-
> From: Yakov Rekhter [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 22, 2002 6:29 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
>
>
> Suresh,
>
> > > > 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.
> > >
> > > 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.
> >
> > 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.
>
> Good. So we are in agreement that the katz-yeung draft can support
> both single area and multi-area TE.
>
> > 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.
>
> That is correct too.
>
> > Inter-area OSPF-TE is a scenario described in
> > kompella-mpls-multiarea-te for faster convergence in LSP computation.
>
> I am not sure which scenario you are referring to. But anyway, this
> is outside the scope of the present discussion...
>
> > 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.
>
> 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...
>
> > 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.
>
> 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 RFC10.
>
> Yakov.





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

2002-12-22 Thread Yakov Rekhter
Suresh,

> > > 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.
> > 
> > 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.
> 
> 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. 

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

> 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. 

That is correct too. 

> Inter-area OSPF-TE is a scenario described in 
> kompella-mpls-multiarea-te for faster convergence in LSP computation.

I am not sure which scenario you are referring to. But anyway, this
is outside the scope of the present discussion...
  
> 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.

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...
  
> 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.

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 RFC10.

Yakov.




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

2002-12-21 Thread Pyda Srisuresh
<... snip>

> > 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.
> 
> 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.

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




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

2002-12-19 Thread Yakov Rekhter
Suresh,

> > > > 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.
> > > 
> > > 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.
> > 
> > The draft is about multi-area TE, as it describes how to solve
> > the problem of supporting TE in a multi-area environment.
>  
> OK.
> 
> > > 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.
> > 
> > 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 - 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". 

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.

> 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.

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.




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

2002-12-19 Thread Pyda Srisuresh
<... snip>

> > > 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.
> > 
> > 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.
> 
> The draft is about multi-area TE, as it describes how to solve
> the problem of supporting TE in a multi-area environment.
> 
OK.

> > 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.
> 
> 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 - 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.

> Yakov. 

regards,
suresh




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

2002-12-19 Thread Yakov Rekhter
Suresh,

> > > 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
> > 
> > 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.
> 
> 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.

The draft is about multi-area TE, as it describes how to solve
the problem of supporting TE in a multi-area environment.
  
> 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.

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. 




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

2002-12-18 Thread Pyda Srisuresh

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
> Kireeti Kompella
> Sent: Wednesday, December 18, 2002 5:16 PM
> To: Pyda Srisuresh
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
> 
> 
> On Wed, 18 Dec 2002, Pyda Srisuresh wrote:
> 
> > > 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.
> > >
> > > ...
> >
> > Kireeti - You apparantly have an attitude and it shows. Outside
> > 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.
> 

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.

> 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.
> 

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.

> > All my comments including those on limitations remain unanswered.
> 
> 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




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

2002-12-18 Thread Pyda Srisuresh
<... snip>

> > 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
> 
> 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.
> 

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




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

2002-12-18 Thread Pyda Srisuresh

> -Original Message-
> From: Kireeti Kompella [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 18, 2002 3:37 PM
> To: Pyda Srisuresh
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
> 
> 
> On Wed, 18 Dec 2002, Pyda Srisuresh wrote:
> 
> ...
> 
> > Hence, a statement of applicability and limitations is
> > warranted in the draft.
> 
> 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.
> 
> ...

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.

> 
> > 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.
> 
> 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.
> 
> ...
> 
> > The whole crux of my comments has been on scaling and applicability
> > limitations.
> >
> > > >Large OSPF networks with multiple areas will not
> > > >run this protocol.
> > >
> > > Crystal ball?  I suggest you get a new one.
> > >
> >
> > 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."
> 

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. 

> Kireeti.

regards,
suresh




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

2002-12-18 Thread Keith Moore
> 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.

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




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

2002-12-18 Thread Pyda Srisuresh
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 


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike
> O'Dell
> Sent: Wednesday, December 18, 2002 1:47 PM
> To: [EMAIL PROTECTED]
> Cc: Mike O'Dell; [EMAIL PROTECTED]
> Subject: Re: Last Call: Traffic Engineering Extensions to OSPF Version 2
> to Proposed Standard
> 
> 
> 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
> 




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

2002-12-18 Thread Mike O'Dell
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




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

2002-12-18 Thread Pyda Srisuresh
<... snip>

>> Hi,
> 
> On Mon, 16 Dec 2002, Pyda Srisuresh wrote:
> 
> > The draft is a solution to providing TE within an OSPF area.
> 
> Yes.
> 
> > 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.
> 
> 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.
> 

You forgot to mention flooding.

> > I would not
> > recommend using this draft as the basis for building further
> > TE-extensions to inter-area and mixed networks.
> 
> Your recommendation is noted.  Of course, that is not the issue at
> 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.

> > The draft apparently evolved over time with no requirements
> > document to guide it.
> 
> 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.

> > The vendors and implementors behind the
> > draft may have been guided by different set of requirements
> > and motivations, such as having some working code.
> 
> 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.

> > 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".
> 
> 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.
> 
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. 

> >Large OSPF networks with multiple areas will not
> >run this protocol.
> 
> 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.

> > 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".
> 
> 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.
> 

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.

> > 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 T

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

2002-12-18 Thread Rohit Dube
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 PROTECTED] 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.












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

2002-12-18 Thread Rohit Dube

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]







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

2002-12-17 Thread Yakov Rekhter
Suresh,

> 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

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.

> 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 PROTECTED]]
> Sent: Tuesday, December 17, 2002 11:46 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 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]
> 
> 




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

2002-12-17 Thread Pyda Srisuresh
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 PROTECTED]]
Sent: Tuesday, December 17, 2002 11:46 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
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]





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

2002-12-16 Thread Pyda Srisuresh
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 PROTECTED]]
Sent: Friday, December 13, 2002 11:13 AM
To: [EMAIL PROTECTED]
Cc: Pyda Srisuresh; [EMAIL PROTECTED]
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 PROTECTED]]On Behalf Of The
IESG
Sent: Monday, November 25, 2002 3:47 PM
To: [EMAIL PROTECTED]
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  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 PROTECTED] or [EMAIL PROTECTED] mailing lists by December 26, 2002

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