Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...)

[Curtis Villamizar <[e-mail]>]

BTW- I think the draft mentioned below by Swallow et al is:

  Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
  extension for recording TE Metric of a Label Switched Path
  draft-ietf-ccamp-te-metric-recording-01.txt

I think there is other related work.  George - help.  Please.

Curtis


In message <[e-mail]>
Curtis Villamizar writes:


Loa, authors, et al,

So far I have seen two of the four MPLS-RT reviews (maybe I missed the
others).  I've commented before on the mailing list about this draft
but at this point I would like to provide a detailed review.

I think there are very major issues with this document as it now
stands.  IMO these issues should be addressed before the draft is even
accepted as a WG document.

You can choose to consider this during MPLS-RT review or after.

Curtis




Major issues:

  Jitter and loss are very close to meaningless if queueing delays and
  loss are not considered.  Links that are losing packets at the link
  layer are generally taken down.  Oscillations can occur if queueing
  delay and loss is considered, such as measurements at a low priority
  and therefore possible to congest or measurements which are
  otherwise affected by traffic load.  Unless there is adequate
  discussion of stability and mechanisms to insure stability, then
  jitter and loss should be removed.

General:

  It needs to be much more clearly stated that the NPO (s/SLA/NPO/g,
  see nits below) is specific to a link, and not an NPO per LSP.  A
  "non-conformance to NPO" flag in the IGP link advertisement is
  intractable if there are multiple NPO being applied to the link.

  The use of a "non-conformance to NPO" flag as the only means to
  alert the set of LSP ingress of a significant change is also at best
  a poor solution.  For example, a change from 2 msec to 15 msec may
  be a problem for some LSP.  That same change may not be a problem
  for others, such as LSPs where only this one hop is needed.  So
  advertising out of NPO in the IGP doesn't help the second case.  LSP
  ingress must evaluate the path delay constraint, each time a change
  in IGP link advertised delay is received.

  The use of a "non-conformance to NPO" flag solely as a constraint
  makes sense, where some LSP are configured to exclude links with
  this flag set.

  For path delay computation it would also be useful if the NPO
  threshhold were advertised.  In some cases, it may make sense to
  minimize or place bounds on the sum of NPO delays.

Specific:

  Abstract:

    Remove mention of jitter and loss.

  1.  Introduction:

    This sentence is awkward but I think I know what you are trying to
    say.

      The method suggested is not optimal for both minimizing path
      cost and additional constraints, such as latency; optimal
      solutions are computationally complex.

    Please consider this replacement.

      Methods of optimizing path selection for multiple parameters are
      generally computationally complex.  The method proposed here are
      to make use of either a single metric in path selection, such as
      minimal path delay, or to make use of another single metric,
      such as the existing TE metric with additional constraints, such
      as target link delay bounds and target path delay bounds.

    Please note:

      The path selection mechanisms described in this document apply
      to paths that are fully computed by the head-end of the LSP and
      then signaled in an ERO where every sub-object is strict.  This
      allows the head-end to consider IGP-distributed performance data
      without requiring the ability to signal the performance
      constraints in an object of the RSVP Path message.

    There is work in MPLS or CCAMP by George Swallow and others on
    cummulative metrics in RSVP-TE with delay as a major motivation.
    Perhaps that work should be considered.

    This paragraph could use rewording:

      When considering performance-based data, it is obvious that
      there are additional contributors beyond just the links.
      Clearly end-to-end latency is a combination of router latency,
      queuing latency, physical link latency and other factors.
      However, if application traffic requires paths to be selected
      based upon latency constraints, the same traffic might be in an
      Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal
      queuing delay or another PHB with known maximal per-hop queuing
      delay.  While traversing a router can cause delay, that can be
      included in the advertised link delay.

    What you are getting at is that where traffic levels can't
    possibly have a significant impact the measurements, such as low
    levels of EF traffic in a WAN with high geographic delays, and
    delay meansured with EF priority, stability is not impacted if
    delay measurements are considered.  In this case, loss MUST be
    zero or the EF service is broken (replace routers and try again).
    OTOH jitter will increase as traffic levels increase, even in such
    a case where the traffic is only a few percent, potentially
    causing oscillations and impacting stability.  For this reason,
    jitter and loss should not be considered.

    I will leave the rewording up to you.  I suggest that you create a
    subsection of "Introduction" which discusses potential
    oscillations and stability in greater detail.  If you like, I will
    provide some text.

  1.1.  Basic Requirements:

    Drop "packet loss, jitter" from the first numeric item.  Otherwise
    OK except use of the word SLA.  See nits below.

    After the list please state that "For existing MPLS constraints,
    corresponding RSVP-TE signaling allows midpoint LSR to use Path
    Tear and/or notification and would use this mechanism to
    accomplish items 3-6.  In the absense of RSVP-TE signaling
    corresponding to these new constraints, new mechanisms at the LSP
    ingress are needed."  Alternately, consider citing the work by
    George Swallow et al and explain how that solves it in the same
    way that a change in admin attr of a link would (or should, poor
    implementations not withstanding).

  2.1.  End-to-End Constraints:

    Note: I've requested that jitter and loss be dropped from
    draft-ietf-ospf-te-metric-extensions and
    draft-previdi-isis-te-metric-extensions for the same potential
    oscillations and stability reasons cited above.

    s/While it has been possible to compute a CSPF/It is possible to
    compute a CSPF/
    s/Instead of this approach to minimize path latency, an/An
    alternative to this approach to minimize path latency is an
    approach to place a upper bound on path latency.  An/
    Note: both approaches are valid.

    Delete next paragraph starting with "This is illustrated as
    follows."  This seems to be taken from email and is good email
    discussion but not needed in the draft.

    Delete next paragraph starting with "An end-to-end bound on delay
    variation".  Lets get rid of jitter altogether.  (Let the old SNA
    networks be damned. :)

    Delete next paragraph starting with "For link loss".  Get rid of
    link loss altogether.

  2.2.  Link Constraints:

    Drop delay variation and link loss.

    If we are dealing with EF traffic then using Unidirectional
    Available Bandwidth and Residual Bandwidth makes no sense.  If we
    are dealing with low priority traffic and we are using
    Unidirectional Available Bandwidth and Residual Bandwidth in path
    selection will be prone to oscillations and network instability.
    Therefore delete the entire second paragraph (the one starting
    with "When doing path selection for TE tunnels,".

    Also delete the entire third paragraph (starting with "Similarly,
    only links whose loss is").  As stated earlier, use of loss is
    either a NOOP (low volume of EF traffic) or can lead to
    oscillations.  Get rid of loss entirely.

  2.3.  Links out of SLA:

    s/SLA/NPO/g (see nits below).

    General: A better mechanism than an "Anomalous State" flag is
    needed to provide notifications of change.  One mechanism would be
    to put the commulative constraint and the cummulative total in the
    ERO and RRO.  A link adding delay can then notify the ingress of
    any LSP for which the commulative constraint is violated.  See
    work by Swallow et al and perhaps align with that work.

    The "Anomalous State" flag is helpful for c in the list, but not
    for b.  The case where a link is out of NPO by 1 msec then changes
    to out of NPO by 10s of msec is an example.  The flag is already
    set and therefore the trigger is unavailable.

  2.3.1.  Use of Anomalous Links for New Paths

    Delete second paragraph regarding jitter and loss.

  2.3.2.  Links entering the Anomalous State

    This section ignores two cases in which the Anomalous State does
    not change but a change makes the path violate a delay
    constraint.  The first is where all of the links are within NPO
    but a change to a link has make the path delay sum exceed the path
    delay constraint.  The second is where a link which is already in
    the Anomalous State by a small margin but the path delay is still
    within the constraint.  A large change in delay at that point will
    not affect the Anomalous State since it is already set.

    A better means of handling case (b) in "2.3.  Links out of SLA" is
    needed.

  2.3.3.  Links leaving the Anomalous State

    Same issue as in "2.3.2.  Links entering the Anomalous State".  A
    better means of handling case (b) in "2.3.  Links out of SLA" is
    needed.

XML version nits:

  CV: you really should remove the template comments.

  You should also enable strict mode.  For example, you have one
  author too many and strict would catch that.

Other nits:

  The "A" in SLA is "Agreement" as in contract.  The acronym NPO for
  network performance objective seems to be in vogue for that reason.
  IETF since diffserv has wanted to steer clear of making
  recommendations regarding provider contracts (agreements) with
  customers, peer, or anyone else.

  I agree with Sri on the suggestions to change the title, short name
  and document filename but I'm not fond of his suggested new names.
  Authors please suggest new title, short name, and filename.


------- Forwarded Message

On 4/5/13 9:50 PM, "Loa Andersson" <[e-mail]> wrote:
>
>Xiaohu, Sri, Rajiv and Pranjal,
>
>You have been selected as an MPLS Review team reviewers for
>draft-atlas-mpls-te-express-path-02.
>
>Note to authors: You have been CC'd on this email so that you can know
>that this review is going on. However, please do not review your own
>document.
>
>Reviews should comment on whether the document is coherent, is it
>useful (ie, is it likely to be actually useful in operational
>networks), and is the document technically sound?  We are interested
>in knowing whether the document is ready to be considered for WG
>adoption (ie, it doesn't have to be perfect at this point, but should be
>a good start).
>
>Reviews should be sent to the document authors, WG co-chairs and
>WG secretary, and CC'd to the MPLS WG email list. If necessary, comments
>may be sent privately to only the WG chairs.
>
>Are you able to review this draft by April 20, 2013?
>
>Thanks, Loa
>(as MPLS WG chair)
>
>/Loa
>-- 
>
>
>Loa Andersson                        email: [e-mail]
>Senior MPLS Expert                          [e-mail]
>Huawei Technologies (consultant)     phone: [phone]

_______________________________________________
mpls mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls

------- End of Forwarded Message