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

[Alex Zinin <zinin@psg.com>]

<RTG AD hat on>

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 larger the number of retransmissions and Acks. 
>          It is undesirable to flood non-TE nodes with TE TLVs.

Kireeti replied:

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

Suresh:

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

The consensus within the WG was to use Opaque LSAs to distribute
TE information and not change the underlying flooding mechanisms
that are critical for the protocol to operate correctly. Given
this, I will agree with Kireeti that the draft does not have to
spell out what is already natural to the protocol and is not
changed. Mentioning this will do no harm, however. I'd leave
this up to the authors as well.

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

Kireeti suggested that there are at least two ways to exclude a link
from the regular IP topology--1) discourage usage of a given link by
announcing the maximum possible link cost in the regular OSPF LSAs,
and 2) not announce a link in regular LSAs at all. Suresh pointed out
that the first method does not completely exclude a link from the
regular topology (indeed, when no alternative path is available, such
a link will still be used.) Though these mechanisms are not perfect,
there does not appear to be consensus that they are inadequate.

To summarize, I would like to thank Suresh for his comments and say
that though there are a couple of places where the document could
benefit from a clarification, no show-stoppers have been identified,
and the draft should go forward. What I would also like to emphasize
is that not only there was an overwhelming consensus on the draft in
the OSPF WG where it was produced (as well as in the GMPLS community
that extended the mechanism to support optical networks), but also the
described mechanism has been implemented by several router vendors,
and deployed in a number of SP networks.

Regards.

Alex