Draft: Summary of discussion on draft-katz-yeung

[Alex Zinin <zinin@psg.com>]

This is the first draft of the summary.
Please see if you would change the approach
somewhere. I'll do another round of wording
purification when I get some comments.

Alex

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

> 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 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. Kireeti suggested adding the following text to clarify this
more:

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

Wrt the mixed network scenarios, there doesn't appear to be consensus
that behavior of the mechanism described in draft-katz-yueng is
incorrect and dangerous for the network. On the contrary, 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.
??? This is not the first time I hear this, though...???

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

See above for 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.

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

>       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), I could also add that the second method is not perfect
either, since it works for point-to-point links only (since
regular IP topology and TE topology share the network-LSAs,
an adjacency on a broadcast network has to appear in the regular
router-LSA to be used in the TE path calculation.) Though these
mechanisms are not perfect, there does not appear to be consensus
that they are inadequate. Given this, as well as the fact that
there doesn't appear to be consensus that stricter separation is
necessary, I would not consider this a show-stopper.
-----------------------------------------------------------