Re: [mpls-tp] Impossible requirements in the MPLS-TP OAM requirements draft? (was: Concerns regarding draft-frost-mpls-tp-loss-delay-00)

["Riccardo Martinotti" <[e-mail]>]

Maarten,

This seems to me a particular case, where the bandwidth profile is not related (and then enforced) to the connection as a whole, but to specific flows within the connection, to be identified either as "EIR only flow" or as "CIR only flow".
How do I treat "CIR and EIR flows" in this case? Usually the bandwidth profile enforcement functions foresee a dual token bucket. 
I prefer a queuing/scheduling Option to be applicable to general cases.

Regards,
Riccardo


-----Original Message-----
From: Maarten Vissers [mailto:[e-mail]] 
Sent: martedì 10 novembre 2009 21.30
To: Riccardo Martinotti
Cc: [e-mail]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM requirements draft? (was: Concerns regarding draft-frost-mpls-tp-loss-delay-00)

Ricardo,

In option B the drop eligible (EIR) traffic is traffic that belongs to a
different flow (within the connection) then the non-drop eligible (CIR)
traffic. 

Because the CIR and EIR traffic components belong to different flows within
the connection, those flows don't have a requirement to preserve order
between the frames/packets of the flows. Order preservation is only required
for the frames/packets belonging to the CIR flow and for frames/packets
belonging to the EIR flow. That is why in Option B it is possible to assign
priority level D to the EIR flow frames/packets and priority level C to the
CIR flow frames/packets.

If the drop eligible (EIR) frames/packets belong to the flow as the non-drop
eligible (CIR) frames/packets, then we have to use Option A and mark both
sets with priority level C and use a drop eligible and non-drop eligible
marking to identify which frames/packets may be dropped at the input of
congested links.

Regards,
Maarten

-----Original Message-----
From: Riccardo Martinotti [mailto:[e-mail]] 
Sent: dinsdag 10 november 2009 20:13
To: Maarten Vissers; Alexander Vainshtein
Cc: [e-mail]
Subject: R: [mpls-tp] Impossible requirements in the MPLS-TP OAM
requirements draft? (was: Concerns regarding
draft-frost-mpls-tp-loss-delay-00)

Maarten,

 

there is a point about traffic ditribution not clear to me. 

It seems to me that Option B may imply out of order delivery 

of packets of medium CoS (e.g. in case some medium EIR packet 

is still in the queue when higher priority traffic arrives, 

together with following medium CIR traffic), 

thus I would suggest Option B to be avoided.

 

Regards,

Riccardo


________________________________

Da: [e-mail] per conto di Maarten Vissers
Inviato: mar 10/11/2009 16.38
A: 'Alexander Vainshtein'
Cc: [e-mail]
Oggetto: Re: [mpls-tp] Impossible requirements in the MPLS-TP OAM
requirements draft? (was: Concerns regarding
draft-frost-mpls-tp-loss-delay-00)



Sasha,

Congestion of links should be measured by monitoring the loading of the
link, not be monitoring the numerous service or tunnel connections passing
over a link. This means that on an Ethernet link you should monitor the
number of transmitted bytes/bits versus the capacity of the Ethernet link.
Operators are already doing this for some time. Initially they got reports
every 15 minute, more recently they get reports every 5 minutes. These
reports are used to engineer the network and plan addition of extra links,
or of rerouting of some of the connections using a link.

To get an understanding of relative fairness of distributing EIR BW among
various clients you will not be able to get such a picture from monitoring
the individual service instances at UNI-N ports. Each service isntance
passes many links, and be grouped with various other service instances on
each link. Dropping a frame/packet at the ingress of a link is a local
process, controlled by the queues, scheduling algorithm and traffic
engineering. Feedback I got more recently on this issue is that the
scheduler in a packet transport network is using strict priority and 4
queues.

There are two distributions of CIR/EIR traffic over those 4 queues being
used:

Option A
========
Queue 1: network control & management traffic (CIR only) Queue 2: premium,
real time traffic (CIR only) Queue 3: medium (CIR + EIR) Queue 4: best
effort (EIR only)

Option B
========
Queue 1: network control & management traffic (CIR only) Queue 2: premium,
real time traffic (CIR only) Queue 3: medium (CIR part) Queue 4: medium (EIR
part) + best effort (EIR only)

Reading from the queues is by means of strict priority, with order of 1
(high) -> 2 -> 3 -> 4 (low).
For option A this implies that the EIR of the medium CoS has priority over
the EIR of the best effort CoS.
For option B all EIR (from medium and best effort CoSs) is treated the same.

Traffic engineering of the links must be performed in such a way that sum of
CIR of the service instance connections passing the link is less then the
link bandwidth.
If sum of CIR is much less then link bandwidth, then EIR traffic will have
same performance as premium traffic (for much lower cost, but without
guarantee).
If sum of CIR is closer to link bandwidth, then EIR traffic will be truly
best effort traffic.

Traffic engineering must also guarantee that the network control &
management traffic takes only a small percentage of the link bandwidths.

Note that the customer traffic may have more class of services defined than
are being used inside the packet transport network. If this is the case,
then these customer classes of service are mapped onto one of the three
lower classes of service inside the packet transport network.

A customer can choose to have a best effort (lowest cost), or medium
(moderate cost), or premium (highest cost) service. If a minimum amount of
frames/packets should be delivered per period, then medium or premium
service should be choosen, otherwise best effort if good enough. If all
frames/packets should be delivered then a medium service with EIR=0 is the
minimum choice. If all frames/packets should be delivered with litle jitter,
then a premium service is to be choosen. Fairness is based on selected
service class (premium, medium, best effort).

Our OAM is required to help
- maintaining the network by detecting degradations and faults at the
infrastructure layers (phy, section, path/tunnel)
- verifying service level agreements, detecting faults and degradations to
compute the number of (severely) errored seconds, unavailable time and
background block errors and to trigger per service instance protection
switching (to prevent entering into unavailable time)
- localization of faults and degradations.

As there is no guarantee for EIR traffic, there seems to be no need to
measure this in a pro-active manner; if a customer needs a guaranteed amount
of traffic to be delivered, he/she should buy a medium or premium service.
If there is a need sometimes to measure frame/packet loss of EIR traffic, it
can be supported in an on-demand basis using LMM/LMR.

This results in the following classes of service for a service layer
connection:
CoS 1: network control & management traffic (CIR only) ==> single priority
(A), no drop eligibility CoS 2: premium, real time traffic (CIR only) ==>
single priority (B) without drop eligibility CoS 3: medium (CIR + EIR) ==>
single priority (C) with and without drop eligibility, or two priorities
(C,D) CoS 4: best effort (EIR only) ==> single priority (D) with drop
eligibility

A service connection with either CoS1, or CoS2 has one priority/drop
eligible flow which can be monitored pro-active or on-demand with a single
frame/packet loss measurement.

A service connection with CoS4 has one priority/drop eligible flow which can
be monitored on-demand with a single frame/packet loss measurement mechanism
capable to monitor drop eligible frames/packets.

A service connection with CoS3 has one two priority/drop eligible flows, of
which the non-drop eligible flow can be monitored pro-active or on-demand
with a a single frame/packet loss measurement, while the drop eligible flow
can be monitored on-demand with a second frame/packet loss measurement
capable to monitor drop eligible frames/packets.


Tunnel connections carry an aggregate of service connections and can carry
as such a mix of CoS1, CoS2, CoS3 and CoS4 traffic. Frame/packet loss
measurements in tunnel connections can be performed on the lowest CIR
priority active in the tunnel. Due to strict priority, CIR traffic in the
lowest CIR priorirty level will be lost before CIR traffic in higher
priority levels will be lost. The loss of CIR traffic in a tunnel is used as
a SD trigger for protection of groups of service connections (1:1 CL-SNCG/I
protection).

Besides detecting frame/packet loss in a tunnel connection to trigger
protection switching and in a service connection to verify the SLA, it would
be helpful to report drop of CIR traffic in the queues at the ingress of a
physical media link. Reporting from the Queues at the link ingress point
provides direct fault localization information (for a congested link) and is
a trigger to check the traffic engineering status of the link... it seems
that there is a mistake made.

Finally, the loss of frames/packets due to bit errors on the physical link
(detected via FCS error check) should be reported as it provides direct
fault localisation information for non-congestion errors.

Regards,
Maarten


-----Original Message-----
From: Alexander Vainshtein [mailto:[e-mail]]
Sent: dinsdag 10 november 2009 14:24
To: Maarten Vissers
Cc: [e-mail]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM
requirements draft? (was: Concerns regarding
draft-frost-mpls-tp-loss-delay-00)


Maarten,
Lots of thanks for relaying a valuable operator input.

As for the number of traffic classes actually in use:

- In MPLS and MPLS-TP you are limited to 8 per LSP (juts so many bits in the
TC/EXP field)
- Whether we need all 8 or can do with 4 looks like a relatively minor issue
to me - once we agree that packet loss
  and delay measurements must be per traffic class. E.g., the fact that the
operator has the right to drop EIR traffic
  (i.e., the  customer cannot claim that the SLA is broken) does not
automatically mean that it does not make any
  sense to measure the packet loss rate for this category of traffic (e.g.,
in order to estimate the congestion levels,
  to verify relative fairness of distributing EIR BW among various clients
etc.).

Regards,
     Sasha



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Maarten Vissers
> Sent: Tuesday, November 10, 2009 1:55 PM
> To: [e-mail]
> Subject: Re: [mpls-tp] Impossible requirements in the MPLS-TP OAM 
> requirements draft? (was: Concerns regarding
> draft-frost-mpls-tp-loss-delay-00)
>
> Feedback I got from an operator in the past on L-LSPs is that 
> customers don't like L-LSPs as it may result in a partly failure of 
> the service (i.e.
> failure of one CoS level).
>
> Nonetheless that there are many CoS levels (priority, drop
> eligibility)
> defined, there are actually only a few in use in **packet transport 
> networks**. Our OAM work must be based on the classes used.
> There are the
> following classes in use:
> 1) network control & management traffic class (1 CoS, CIR only)
> 2) premium, real time traffic (1 CoS, CIR only); latency and frame 
> delivery guaranteed
> 3) medium (2 CoSs, CIR plus EIR); latency not guaranteed, frame 
> delivery guaranteed for CIR traffic, no guarantee for frame delivery 
> of EIR traffic
> 4) best effort (1 CoS, EIR only); latency not guaranteed, frame 
> delivery not guaranteed.
>
> Frame/packet loss should monitor the loss of the CIR traffic.
> The EIR traffic is always a best effort traffic for which no 
> guarantees exist in the SLA, so no need to monitor it.
>
> Regards,
> Maarten
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
> Sent: dinsdag 10 november 2009 4:57
> To: Dan Frost; Stewart Bryant
> Cc: [e-mail]
> Subject: [mpls-tp] Impossible requirements in the MPLS-TP OAM 
> requirements draft? (was: Concerns regarding
> draft-frost-mpls-tp-loss-delay-00)
>
> Dan, Stewart and all,
> I've changed the subject line and added the Editors of the MPLS-TP OAM 
> Requirements draft, Loa  (who is the shepherd of the same
> draft) and Adrian
> to the CC list.
>
> I've done that because, FWIW, my understanding of the outcome of our 
> discussion (as it has been recorded by Dan) is that the requirements 
> posted in Section 2.2.11 and, presumably, 2.2.12 of
> draft-ietf-mpls-tp-oam-requirements-03
> (now in the IESG discussion) in their present form CANNOT BE MET.
>
> This is because packet loss (and, IMHO, packet delay) measurements 
> across entities that carry multiple traffic classes are meaningless.
> Of the three
> entities mentioned in these requirements, PWs and Sections definitely 
> carry multiple traffic classes. LSPs do that also unless we restrict 
> them to be L-LSPs only. While such a restriction is possible in 
> principle, its impact (e.g.,  on scalability and on interoperability 
> with the existing IP/MPLS) would be IMHO quite destructive.
>
> I apologize for sending this comment so late; it should be sent during 
> the WG and/or IETF LC on the draft.
> But late is (hopefully) better than never.
>
> Am I possibly jumping to wrong conclusions?
>
> My 2c,
>      Sasha
>
>
>
>
> > -----Original Message-----
> > From: Dan Frost [mailto:[e-mail]]
> > Sent: Monday, November 09, 2009 4:55 PM
> > To: Alexander Vainshtein; Stewart Bryant
> > Cc: [e-mail]
> > Subject: Re: Concerns regarding draft-frost-mpls-tp-loss-delay-00
> >
> > The draft authors and Sasha had an extended discussion
> today at IETF76
> > that covered most of these topics; I'll try to summarise the main
> > points:
> >
> > - while measurement accuracy is certainly an important concern, it 
> > seems
> >   best addressed at the equipment/implementation spec level in this
> >   case.
> > - with regard to the clock requirements for two-way delay
> measurement,
> >   the draft speaks at the system level; it's of course true that 
> > within
> >   a distributed system the clocks of the tx/rx cards must be
> >   synchronized; this can be clarified.  In general we can
> elaborate on
> >   the wall clock sync considerations for DM.
> > - we are aware the -00 text does not deal explicitly with the 
> > connection
> >   to QoS and this is already due for update.  The short version is 
> > that
> >   LM/DM are best described as operating not with respect to a 
> > transport
> >   entity (e.g. LSP) as such but with respect to a particular packet
> >   profile for a transport entity that specifies the set of packets 
> > under
> >   consideration; that this profile cannot span multiple QoS
> classes;
> > and
> >   that this profile must match at both endpoints.  (This
> also subsumes
> >   the current text of Sec. 4.1.6 about whether or not OAM
> packets are
> >   included in LM.)
> > - we are aware of the important role of other LM methods such as
> >   synthetic measurement approaches (based on, for example, using OAM
> >   messages as a proxy for inferring data-plane loss) which provide a
> >   lower grade of LM but which can be much easier/cheaper to
> implement.
> >   The consensus among those we've spoken with is that the synthetic 
> > and
> >   Y.1731-style approaches are complementary.  We would therefore 
> > expect
> >   to expand a little on the other approaches in this draft
> and produce
> >   at least one additional draft on synthetic LM for MPLS-TP.
> >
> > We thank Sasha for the comments and discussion!
> >
> > -d
> >
> > Alexander Vainshtein <[e-mail]> writes:
> > > Dan, Stewart and all,
> > > I have serious concerns regarding the above-mentioned
> > draft, and I'd like
> > > to share them with you and the list prior to discussion at
> > the MPLS-TP
> > > Hiroshima sessions.
> > >
> > > The requirements (as presented in the draft) are for measuring:
> > >
> > >  1. Packet loss ratio over a PW, LSP or a Section
> > >
> > >  * The packet loss ratio is defined as the ration of the
> number of
> > > delivered user packets to the total number of the user
> packets over
> > > a specified interval
> > >  * The measurement should rely on the user traffic
> > >  * The measurement mechanisms must apply to P2P
> unidirectional, P2P
> > > bi-directional (co-routed and associated) and P2MP LSPs
> > >
> > >  2. One-way and, if necessary, two-way delay of a PW, LSP
> > and Section
> > >
> > >  * Two-way measurements only apply for bi-directional LSPs,
> > >  * One-way measurements apply for all  kinds of LSPs.
> > >
> > > My concerns start from the fact that, while we are dealing with 
> > > measurements, the specification of desired and achievable
> > accuracy of
> > > these measurements is completely lacking. This holds for
> > both types of
> > > measurements discussed in the draft.
> > >
> > > Specific concerns with one-way vs. two-way delay measurements.
> > >
> > >  1. The draft actually states that, in order to do one-way delay 
> > > measurements, the wall clock at the two end points of the
> > measurement
> > >  must be synchronized. It also states that the ways of obtaining 
> > > synchronized clock at the two end points are beyond its scope.
> > >  2. At the same time, it states that two-way delay
> > measurements (where
> > >  applicable) only require that the end point clocks are stable.
> > >  3. What the draft does not mention that, even in the case
> > of two-way
> > >  delay measurements, synchronized wall clocks must be
> > available at the
> > >  ingress and egress points of a bi-directional object for
> > which these
> > >  measurements are performed.
> > >
> > >  * This can be problematic for an associated
> bi-directional LSP or a
> > > PW (e.g., if their ingress and egress points reside in different 
> > > line cards).
> > >  * Bi-directional co-routed LSPs and Sections are probably OK (at 
> > > least if you do not have composite interfaces).
> > >
> > >  4. It seems that an explicit applicability statement
> > listing concerns
> > >  about synchronized clocks, and impact of accuracy of their 
> > > synchronization on the accuracy of the delay measurements
> would be
> > > very much in place  5. Comparison with the techniques
> developed by
> > > in the IPPM
> > WG (e.g., RFC
> > >  2679) would be very much in place.
> > >
> > >
> > > Packet loss measurements raise more serious concerns.
> > >
> > >
> > >  1. The MPLS-TP framework draft explicitly states that both
> > E-LSPs and
> > >  L-LSPs are supported in MPLS-TP.
> > >
> > >  * Support of E-LSPs means that a single LSP can carry
> multiple (up
> > > to 8) classes of service (CoS)
> > >  * Running multiple CoS over the same LSP IMHO has
> serious impact on
> > > packet loss measurements:
> > >
> > > * Conceptually, it is far from clear whether a single packet
> > >   loss measurement across multiple classes of service makes
> > >   any sense whatsoever
> > > * Protocol-wise, the solution proposed in the draft relies
> > >   (implicitly) on the assumption that the user traffic and the
> > >   measurement packets are delivered in order across the entity
> > >   for which this measurement is performed - which, of course,
> > >   is broken with E-LSPs
> > > *
> > >  2. The same set of considerations apply for measuring
> > packet loss for PWs
> > >  (which, IMHO, in this context, are not different in any
> way from
> > > associated bi-directional LSPs)  3. The problem becomes even more 
> > > interesting for MPLS-TP Sections:
> > >
> > >  * On one hand, the assumption that a single MPLS-TP
> section carries
> > > only one CoS looks unrealistic
> > >  * On the other hand, it is far from clear if an MPLS-TP
> Section can
> > > re-order the packets:
> > >
> > > * Consider the case where a pair of adjacent MPLS-TP routers
> > >   is connected via a 802.1p-aware L2 switch
> > > * I have not, so far, found, any explicit prohibition of such
> > >   an interconnection in the MPLS-TP documents. Did I miss it
> > >   somehow?
> > >
> > >  4. In addition to carrying multiple CoS over LSPs, PWs and
> > Sections, all
> > >  of these are capable of carrying packets with different
> levels of
> > > drop precedence. (This holds for L-LSPs as well.).
> > >
> > >  * The packet loss definition in the draft seems to ignore the 
> > > differences between packets with different drop precedence levels.
> > >  * This is different from, say, the definitions proposed in ITU-T
> > > Y.1731 (02/08), which explicitly states that these
> measurements must
> > > take into account only what it calls "in-profile" user traffic.
> > >
> > >  5. IMHO, the definition of the packet loss should take into 
> > > consideration multiple CoS (where applicable) and multiple
> > precedence
> > >  levels. Once this is done, the protocol can be adjusted
> > accordingly.
> > >  6. Last but not least, there is an issue with the impact
> > of  of dedicated
> > >  HW features on the accuracy of the packet loss measurements:
> > >
> > >  * The draft states that such an impact exists
> > >  * Alternative techniques (e.g., packet loss measurements
> based on
> > > synthetic traffic similar to RFC 2680) are not
> considered, even for
> > > comparison.
> > >
> > > Hopefully, these notes will be useful.
> > >
> > > Regards,
> > >   Sasha
> >
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> =

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