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

[Loa Andersson <[e-mail]>]

Authors,

Please consider and address Curtis' comments as if they were part
of the MPLS-RT review.

We will have the third MPLS-RT review later today, and hope to have the
last showing soon. Please wait to re-spin the draft until we tell you
to do so, discussing and resolving comments on the wg mailing list
is OK.

/Loa
for the The Great and Mighty MPLS Co-Chairs ;)


On 2013-04-23 18:58, Curtis Villamizar wrote:
> 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
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]