[OSPF] draft-ietf-ospf-te-metric-extensions-04

Curtis Villamizar <curtis@ipv6.occnc.com> Sat, 15 June 2013 15:47 UTC

Return-Path: <curtis@ipv6.occnc.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B243821F9DDE for <ospf@ietfa.amsl.com>; Sat, 15 Jun 2013 08:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecBCtcdXchI5 for <ospf@ietfa.amsl.com>; Sat, 15 Jun 2013 08:47:24 -0700 (PDT)
Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD0C21F9DD6 for <ospf@ietf.org>; Sat, 15 Jun 2013 08:47:24 -0700 (PDT)
Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r5FFk6g1043117; Sat, 15 Jun 2013 11:46:08 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201306151546.r5FFk6g1043117@gateway1.orleans.occnc.com>
To: draft-ietf-ospf-te-metric-extensions@tools.ietf.org
From: Curtis Villamizar <curtis@ipv6.occnc.com>
Date: Sat, 15 Jun 2013 11:46:06 -0400
Cc: ospf@ietf.org
Subject: [OSPF] draft-ietf-ospf-te-metric-extensions-04
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@ipv6.occnc.com
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ospf>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jun 2013 15:47:29 -0000

Spence et al,

Since this is a working group document, I am copying the WG mailing
list.

The document has come a long way.  There are a few changes that need
to be made.  Most significant is addressing the topic of network
stability and oscillations.

You need to do one of the following.  Pick one.

  1.  Explain conditions under which stability can be insured and
      conditions under which oscillations are likely or certain to
      occur.  This is not that hard.

  2.  Change the SHOULD NOT to MUST NOT in the statement about not
      including queuing contributions to delay, jitter, and loss.  If
      you do this, jitter and loss are useless and should be removed
      entirely from the set of extensions.

So far you have indicated that you don't want the first option but are
unwilling to go with the second option.  As is, the document is
unacceptable.

When submitting you should check the nits prodused by idnits.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Line 572 has weird spacing: '...figured  upper...'


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative
     references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'RFC4203' is mentioned on line 189, but not
  defined

  == Missing Reference: 'RFC4206' is mentioned on line 500, but not
  defined

  == Missing Reference: 'RFC5329' is mentioned on line 653, but not
  defined

  == Unused Reference: 'RFC2328' is defined on line 677, but no
  explicit
     reference was found in the text

  == Unused Reference: 'RFC3031' is defined on line 679, but no
  explicit
     reference was found in the text


     Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 0 comments
     (--).

     Run idnits with the --verbose option for more detailed
     information about the items above.

As a matter of style, when defining a TLV, the description of the
individual fields should not be subsections.  These should be done as
a hanging indent list.

If there is no way to do that in the word template, then that is one
more reason to abandon use of word and convert the document to xml2rfc
format.  In the long run if you ever want to make this an RFC it will
probably be a lot less work to convert now.

Normally the ascii art for the TLV layout is followed by the hanging
indent list.  The list has brief descriptions of what each field
represents.  Futher discussion of how the fields are used together in
the TLV follow the list (not in the list and therefore not indented).
You will end up changing this at some point so it might as well be
done now.  See RFC3630 or RFC5105 or any RFC defining TLVs for
examples of how to format this.

As you mentioned, there is a mix of min/max and low/high and it should
all become low/high.

So much for nits.  On to substative comments.

This statement does not adequately address stability and oscillation:

   While this document does not specify how the performance
   information should be obtained, the measurement of delay SHOULD NOT
   vary significantly based upon the offered traffic load.  Thus,
   queuing delays and/or loss SHOULD NOT be included in any dynamic
   delay measurement.  For links, such as Forwarding Adjacencies, care
   must be taken that measurement of the associated delay avoids
   significant queuing delay; that could be accomplished in a variety
   of ways, including either by measuring with a traffic class that
   experiences minimal queuing or by summing the measured link delays
   of the components of the link's path.

The above sentences appear within somewhat of a run-on paragraph in
"1. Introduction".  The only other mention of queu* is in "7. Network
Stability and Announcement Periodicity" in the following short
paragraph.

   Furthermore, it is RECOMMENDED that any underlying performance
   measurement mechanisms not include any significant buffer delay,
   any significant buffer induced delay variation, or any significant
   loss due to buffer overflow or due to active queue management.

What I suggest you do is move this block of text from "Introduction"
to "Network Stability and Announcement Periodicity" and leave a
forward reference in "Introduction".

 OLD:

   Note that the mechanisms described in this document only
   disseminate performance information.  The methods for initially
   gathering that performance information, such as [RFC6375], or
   acting on it once it is distributed are outside the scope of this
   document.  Example mechanisms to measure latency, delay variation,
   and loss in an MPLS network are given in [RFC6374].  While this
   document does not specify how the performance information should be
   obtained, the measurement of delay SHOULD NOT vary significantly
   based upon the offered traffic load.  Thus, queuing delays and/or
   loss SHOULD NOT be included in any dynamic delay measurement.  For
   links, such as Forwarding Adjacencies, care must be taken that
   measurement of the associated delay avoids significant queuing
   delay; that could be accomplished in a variety of ways, including
   either by measuring with a traffic class that experiences minimal
   queuing or by summing the measured link delays of the components of
   the link's path.

 NEW:


   The mechanisms described in this document only disseminate
   performance information.  The methods for initially gathering that
   performance information, such as [RFC6375], or acting on it once it
   is distributed are outside the scope of this document.  Example
   mechanisms to measure latency, delay variation, and loss in an MPLS
   network are given in [RFC6374].  While this document does not
   specify how the performance information should be obtained, the
   measurement of delay SHOULD NOT vary significantly based upon the
   offered traffic load.  Refer to "Section 7. Network Stability and
   Announcement Periodicity" for precautions to insure network
   stability.

Since buffer and queue mean the same thing and the preferred term is
queue, the existing paragraph should be reworded and the text removed
from "Introduction", also reworded should be included.  Further
precautions should be included.

 OLD:

   Furthermore, it is RECOMMENDED that any underlying performance
   measurement mechanisms not include any significant buffer delay,
   any significant buffer induced delay variation, or any significant
   loss due to buffer overflow or due to active queue management.

 NEW:

   Any underlying performance measurement mechanisms SHOULD NOT
   include any significant queuing delay, any significant queuing
   induced delay variation, or any significant loss due to queue
   overflow or due to active queue management.  For links over an
   underlying layer which may already introduce some queue effects,
   such as pseudowire or PSC LSP advertised as Forwarding Adjacencies
   (FAs), care must be taken that measurement of the associated delay
   avoids significant queuing delay.  This could be accomplished in a
   variety of ways, including either measuring with a traffic class
   that experiences minimal queuing or by summing the measured link
   delays of the segments of the FA's path if these are known to
   exclude queue effects.

   If any queuing induced delay, jitter, or loss are included, then
   precautions MUST be taken to insure stability and avoid
   oscillations.  Situations in which oscillations are minimized
   include those where the traffic over which delay and loss
   measurements are made constitute a small minoring of traffic flow
   and where the traffic over which delay and loss measurements are
   made is able to preempt other traffic to obtain a better path.  In
   such a situation, movement of traffic may be transient and mostly
   in response to major events such as network faults.

   If the level of the traffic over which delay and loss measurements
   are made significantly affects the measurements, then oscillations
   are insured.  This is particularly true for jitter, where
   measurements even over a highly preferred minority of traffic will
   be affected by the levels of traffic.  Use of long measurement and
   traffic engineering timers will not eliminate the oscillation, but
   will increase the period of the continuous oscillation cycle.
   This practice will not minimize the measured parameter on the path
   taken by the majority of traffic.  The tendency will be to
   concentrate traffic on a set of links advertised at a given time as
   the best path.  When timers expire, the concentration of traffic
   will move away from their existing overutilized paths onto a
   different, previously underutilized paths, overutilizing these.

   This type of route oscillation over a long period is known as route
   slosh.  Route slosh is disruptive and results in poor end-user
   network performance, with continuous change in delay and with
   regular brief periods of packet reordering.

   There are situations where even a relatively long timer interval,
   such as intervals of a minute or more, will reduce but not prevent
   oscillations.  An example is a lower layer low probability of loss
   that results in an intermittent switch to protection resources with
   an automatic reversion to working path when loss falls below a
   given fault threshold.  This is characteristic of insufficient
   hysteresis at a lower layer.

   Fixed announcement and LSP reroute timers are somewhat analogous to
   a fixed low pass filter in electronics.  Low frequency oscillations
   are unaffected by the filter.

The compatibility section is too brief and is inadequate.  Note: no
period at the end of the sentence.

 OLD:

   As per (RFC3630), unrecognized TLVs should be silently ignored

 NEW:

   If a non-compliant LSR does not advertise delay, jitter, or loss
   for its adjacencies, then LER can either choose to assume default
   (high) values, or avoid creating paths using these LSR for LSP that
   have delay, jitter, or loss requirements.

   As per (RFC3630), unrecognized TLVs should be silently ignored.  A
   non-conformant LER should be unaffected by the presence of the TLVs
   defined in this document.

Note: possible errata to RFC3630.  The statement is "Unrecognized
types are ignored." and is made twice in RFC3630.  This statement
should use RFC2119 wording and IMO should be replaced by "Unrecognized
types MUST be ignored."

These comments apply to the draft-previdi-isis-te-metric-extensions as
well as to draft-ietf-ospf-te-metric-extensions when
isis-te-metric-extensions is updated.

Curtis