Subject: [mpls-tp] Concerns regarding draft-frost-mpls-tp-loss-delay-00

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 9 Nov 2009 05:01:06 +0200

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

---

From: Adrian Farrel <[email-masked]>
Date: Mon, 09 Nov 2009 03:12:42 +0000

All, without making any comments on the technical content of the draft or 
Sasha's email, please be aware that during IESG review of the MPLS-TP OAM 
Requirements draft we have been taken to task for not mentioning RFC 2680 
for packet loss, and RFC 2679 and RFC 2681 for packet delay.

If we propose to diverge from these RFCs (which I understand is aligned with 
the ITU-T's work) we can, but we need to make the case.

Adrian
----- Original Message ----- 
From: "Alexander Vainshtein" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 09, 2009 3:01 AM
Subject: [mpls-tp] Concerns regarding draft-frost-mpls-tp-loss-delay-00

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.

 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.

 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.

 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.

Regards,
     Sasha

--------------------------------------------------------------------------------

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Dan Frost <[email-masked]>
Date: Mon, 09 Nov 2009 14:54:35 +0000

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 <[email-masked]> 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.
>
> delivered user packets to the total number of the user packets
> over a specified interval
> measurements, the specification of desired and achievable accuracy of
> these measurements is completely lacking. This holds for both types of
>  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.
>  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).
>
>  about synchronized clocks, and impact of accuracy of their
>  synchronization on the accuracy of the delay measurements would be
>  very much in place
> * Conceptually, it is far from clear whether a single packet
>   loss measurement across multiple classes of service makes
>   any sense whatsoever
>   (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
> *
>  (which, IMHO, in this context, are not different in any way from
>  associated bi-directional LSPs)
> * 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?
>
>  of these are capable of carrying packets with different levels of 
>  drop precedence. (This holds for L-LSPs as well.).
>
> 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.
> synthetic traffic similar to RFC 2680) are not considered, even
> for comparison.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 05:56:37 +0200

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:[email-masked]] 
> Sent: Monday, November 09, 2009 4:55 PM
> To: Alexander Vainshtein; Stewart Bryant
> Cc: [email-masked]
> Subject: Re: Concerns regarding draft-frost-mpls-tp-loss-delay-00
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 06:20:34 +0200

Dan, Stewart and all,
I've added Yoshinori to the CC list, because this email has been triggered b the discussion of
draft-koike-ietf-mpls-tp-oam-maintenance-points-00 at the MPLS WG session yesterday.

The point I'd like to raise refers to the following definition  that appears both in the MPLS-TP OAM
requirements draft and id draft-frost-mpls-tp-loss-delay:

<quote>
   The number of user packets not delivered is the difference between the number of user packets
   transmitted by an End Point and the number of user packets received at an End Point.
<end quote>

My question is: How does one count packets transmitted by an End Point?

Consider a situation shown in the enclosed diagram below:

The entity hat is monitored for packet loss has its source EP in Router A, crosses Router  and has its sink in Router C.
(I say "entity" instead of "LSP" or "PW" because, as we have already agreed, packet loss measurements apply to a certain CoS and drop precedence level within these).

If the link BC is congested, and some packets belonging to the monitored entity are dropped due to congestion there, they will be clearly counted as "user packets not delivered".

But what happens if the link AB is congested, and some packets belonging to the monitored enmity are dropped due to congestion at this point? These packets are not transmitted in the direct sense of this word, since they never touch the wire. But neither are they delivered.

One could possibly argue that, in transport networks, packets with lowest drop precedence level should not be dropped due to congestion. But IMHO this would mean that the packet loss measurement tool, in addition to being quite complex, would only yield meaningful results in the situations that do not require any OAM tools (because everything works OK).

Did I miss something important?

My 2c again,
     Sasha

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 10 Nov 2009 07:41:19 +0100

Sasha,

Could you be a little bit more specific about the reason why you think
these requirements cannot be met?

In particular knowing that a solution to this problem exists and works
perfectly.

Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: Tuesday, November 10, 2009 12:57 PM
> To: Dan Frost; Stewart Bryant
> Cc: [email-masked]
> 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 
> 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 
> 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.
> > >  * Support of E-LSPs means that a single LSP can carry 
> multiple (up
> > > to 8) classes of service (CoS)

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 08:56:33 +0200

Italo,
I believe I've explained my point: packet loss measurements across an entity
that carries multiple traffic classes is, IMHO, both meaningless and  impossible
to implement (see my original comment on draft-frost).
 And MPLS-TP entities carry multiple traffic classes. 

Could you please clarify what specific existing solution do you have in mind?

(If you refer to ITU-T Y.1731: it acknowledges that frame loss can be only measured per priority level (which is the
equivalent of class of service) and restricts it  to the  so-called "in profile" user packet . 
If you have anything else in mind, please elaborate.)

Regards,
     Sasha

> From: BUSI ITALO [mailto:[email-masked]] 
> Sent: Tuesday, November 10, 2009 8:41 AM
> To: Alexander Vainshtein; Dan Frost; Stewart Bryant
> Cc: [email-masked]
> Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP 
> OAM requirements draft? (was: Concerns regarding

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 10 Nov 2009 08:28:06 +0100

Sasha,

If I understand well, your concerns is not the fact that we cannot
measure packet loss for multiple traffic classes, rather we cannot
meaure packet loss for not "in profile" user data.

Did I miss something?

Thanks, Italo

> From: Alexander Vainshtein [mailto:[email-masked]] 
> Sent: Tuesday, November 10, 2009 3:57 PM
> To: BUSI ITALO
> Cc: [email-masked]; Dan Frost; Stewart Bryant
> (If you refer to ITU-T Y.1731: it acknowledges that frame 
> loss can be only measured per priority level (which is the

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 09:31:33 +0200

Italo,
Actually, both items are problematic.

And the problem starts from the definitions in he MPLS-TP OAM requirements draft that request these measurements
per LSP, PW or Section, ignoring traffic class and drop precedence distinctions.

You can reformulate requirements, of course.

Regards,
     Sasha

> Sent: Tuesday, November 10, 2009 9:28 AM
> To: Alexander Vainshtein
> > From: Alexander Vainshtein
> [mailto:[email-masked]]
> > > > > Alexander Vainshtein
> <[email-masked]> writes:
> > > > > > Dan, Stewart and all,

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 10 Nov 2009 08:35:20 +0100

Hello Sasha,

>  And MPLS-TP entities carry multiple traffic classes. 

If MPLS-TP is used in a transport network it should carry only one class
of service (as Neil pointed out as well).
Carrying more than one CoS would make it also diffult to provide
the required availability by using protection switching.

> equivalent of class of service) and restricts it  to the  so-called "in profile" user packet . 

Correct, and Y.1731 is for carrier class Ethernet used in a transport
network.

Regards, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: David Allan I <[email-masked]>
Date: Tue, 10 Nov 2009 02:48:04 -0500

I have to agree with Sasha and the explanation of course is very simple...and I would hope self evident such that I'm actually being pendantic to this group....

Any exchange of counters to do LM needs to have the counters reflect the class of interest, and the LM PDUs need to be exchanged with the same queuing discpline as the measured class of traffic so packets "in flight" are accounted for...

Anything else will produce variances in the count if any queuing is encountered...PM that only works in an empty network being a somewhat useless function ;-)

I would agree that any such shortcomings in the requirements should be addressed

My 2 cents
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, November 10, 2009 2:32 AM
To: BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Impossible requirements in the MPLS-TP OAM requirements draft? (was: Concerns regarding draft-frost-mpls-tp-loss-delay-00)

Italo,

And the problem starts from the definitions in he MPLS-TP OAM requirements draft that request these measurements per LSP, PW or Section, ignoring traffic class and drop precedence distinctions.

Regards,
     Sasha

> Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM
> > Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM
> > I believe I've explained my point: packet loss measurements across
> > an entity that carries multiple traffic classes is, IMHO, both
> > meaningless and  impossible to implement (see my original comment on
> > draft-frost).
> > (If you refer to ITU-T Y.1731: it acknowledges that frame loss can
> > be only measured per priority level (which is the equivalent of
> > class of service) and restricts it  to the so-called "in profile"
> > user packet .
> > > Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM
> > > > 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,
> > > > 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.
> > > > > >  associated bi-directional LSPs)  3. The problem becomes
> > > > > > even more interesting for MPLS-TP
> > > > Sections:
> > > > > >

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 09:56:44 +0200

Huub,
You can restrict MPLS-TP to supporting only L-LSPs by changing the MPLS-TP framework draft.
As I have said, the implications for scalability would be destructive IMHO.

You cannot, IMO restrict Sections to carrying just one traffic class unless you propose to carry each TC
on its own fiber (or lambda). This sounds to me like making MPLS-TP undeployable, but you should
ask the operators on the list. 

And, to the best of my knowledge, Ethernet PWs carry multiple traffic classes today, and, in this way have been
successfully deployed as Ethernet Services by transport operators all over the world. 
Again, I would be happy to hear, what the transport operators have to say about that, namely, are they 
ready to replace a single PW with multiple (one per traffic class) instances just to be able to say that they
can now measure packet loss per PW?

Regards,
     Sasha

> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: Tuesday, November 10, 2009 9:35 AM
> To: [email-masked]
> Subject: Re: [mpls-tp] Impossible requirements in the MPLS-TP 
> OAM requirements draft?
> 
> Hello Sasha,
> 
> You replied:
> 
> > Italo,

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 08:37:24 -0000

Good points Dave....when you also say "PM that only works in an empty
network being a somewhat useless function ;-)"  you are of course
correct, but the reality is that real-world networks MUST operate at
relative low average utilisations over the vast majority of their
working life for very good engineering reasons (let alone bad ones, like
LDP merging constructs with no ability to control traffic vectors), eg
-	traffic forecast vectors have large error bars (as anyone who
has run a network design group like I have should be able to testify)
-	server BW comes in increasingly larger quanta at the start of a
planning cycle
-	daily peak/mean traffic load variance
-	at *end* of planning cycle need to have at least ~30% redundancy
for resilience
-	at *end* of planning cycle must still meet PM SLAs even at worse
case daily peak traffic load.

To the LHS of the congestion knee (>>99% of time, at least in core
networks) having different QoS classes is of no practical benefit at all
and is just an unnecessary cost (ie all QoS classes look alike).  To the
RHS of the congestion knee the network is usually in severe resource
shortfall due to events like failures....here the application *temporal
importance* requirement is not key, it is the *survivability importance*
requirement that is key...and any application (message/file/stream) can
assume any survivability importance.  {Aside=> Networks do not usually
spend any significant time hoevering around the congestion knee...they
are either well to the LHS of it or well to the RHS of it, and transit
very quiackly between these states.}

A transport network MUST NOT make a judgement call on survivability
importance at the application level (even assuming it could see the
ultimate application, possibly >1 layer network above it, never mind the
fact that it MUST NOT see the application - see below).

BTW the above illustrates a key difference between the co-ps mode and
the cl-ps mode....in the former, and esp in a transport role, the
survivability importance is a function of the *parent connection* and
not its *child traffic units*.

As I have noted before, and I was very pleased to see Huub also pick-up
on this, a transport network MUST NOT try and infer meaning of its
clients.....which practically means the temporal ordering of client
symbols (which practically means at the bit level) MUST be preserved in
a transport network.

If one ignores the G.800 information-theoretic transparency requirement,
which is THE principle service of a transport network, then one surely
cannot ignore the practical consequences of this, eg:
-	if the server can infer meaning of the client symbols then there
is, by definition, functional coupling of client and server
networks...this is therefore not a transparent client/server
relationship and one cannot develop/change either client or server layer
networks independently (which is a very bad arch position to be in);
-	if one has some threshold criteria, like entry/exit of SD or,
even worse, the unavailable state for QoS classes X Y and Z say, this
will be not be practically tractable to implement for the parent
connection (hopefully obvious why)...noting also that QoS counters for
SLAs MUST be disabled (both directions for p2p case) on entering the
unavailable state....even on an end-end basis, let alone with any nested
TCM levels!

So, to be clear, the QoS requirement on a transport network is very
simple and must not be ignored (even though I do not think this has been
adequately captured yet for MPLS-TP):

A connection in a transport network MUST NOT have multiple QoS classes
(a forced behaviour in the co-cs mode, which this is one key reasons why
it is THE de facto transport network mode).  The critical service a
transport network provides to its clients is transparency.  Put simply
this means the server MUST NOT try infer client symbols meaning and all
client symbols MUST have their temporal ordering preserved.

regards, Neil 

> [mailto:[email-masked]] On Behalf Of David Allan I
> Sent: 10 November 2009 07:48
> To: Alexander Vainshtein; BUSI ITALO
> Cc: [email-masked]
> I have to agree with Sasha and the explanation of course is 
> very simple...and I would hope self evident such that I'm 
> actually being pendantic to this group....
> 
> Any exchange of counters to do LM needs to have the counters 
> reflect the class of interest, and the LM PDUs need to be 
> exchanged with the same queuing discpline as the measured 
> class of traffic so packets "in flight" are accounted for...
> 
> Anything else will produce variances in the count if any 
> queuing is encountered...PM that only works in an empty 
> network being a somewhat useless function ;-)
> 
> And the problem starts from the definitions in he MPLS-TP OAM 
> requirements draft that request these measurements per LSP, 
> PW or Section, ignoring traffic class and drop precedence 
> distinctions.
> 
> > > Could you please clarify what specific existing solution 
> do you have 
> > > in mind?
> > >
> loss can 
> > > > > > - we are aware the -00 text does not deal 
> explicitly with the 
> > > > > > connection
> > > > > >   LM/DM are best described as operating not with 
> respect to a 
> > > > > > transport
> > > > > > >  5. Comparison with the techniques developed by 
> in the IPPM
> > > > > > WG (e.g., RFC
> > > > > > >  1. The MPLS-TP framework draft explicitly states 
> that both
> > > > > > E-LSPs and
> > > > > > >  4. In addition to carrying multiple CoS over 
> LSPs, PWs and
> > > > > > Sections, all
> > > > > > > differences between packets with different drop 
> precedence 
> > > > > > > levels.

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 08:54:02 -0000

Sasha....welcome to the real world of transport networks!  But please
observe that a SDH VC4, or PDH/OTN say, cares nothing about its clients
(esp at the application level)...it just gives all its clients
transparent carriage at the bit level *and* survivability importance is
handled at the connection level.  This is just the way it is.  If one
wants to provide a transport network service using the co-ps mode, then
one needs to emulate much of the co-cs mode behaviour.

Aside=> If you owned/ran a client network, any mode but let's say an
IPv4 network, and you did NOT have a transparent transport service from
the service provider who provided your link connections you would be up
in arms...and quite rightly.  One can't have it both ways...one has to
be consistent.

regards, neil 

> Sent: 10 November 2009 07:57
> To: [email-masked]
> Cc: [email-masked]
> You cannot, IMO restrict Sections to carrying just one 
> traffic class unless you propose to carry each TC on its own 
> fiber (or lambda). This sounds to me like making MPLS-TP 
> undeployable, but you should ask the operators on the list. 
> 
> And, to the best of my knowledge, Ethernet PWs carry multiple 
> traffic classes today, and, in this way have been 
> Again, I would be happy to hear, what the transport operators 
> have to say about that, namely, are they ready to replace a 
> single PW with multiple (one per traffic class) instances 
> just to be able to say that they can now measure packet loss per PW?
> 
> Regards,
>      Sasha
> 
> > Subject: Re: [mpls-tp] Impossible requirements in the MPLS-TP OAM 
> > requirements draft?
> > 
> > Hello Sasha,
> > 
> > You replied:
> > 
> > > Italo,
> > If MPLS-TP is used in a transport network it should carry only one 
> > class of service (as Neil pointed out as well).
> > Carrying more than one CoS would make it also diffult to 
> provide the 
> > required availability by using protection switching.
> > 
> > >>> 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.
> > >>>
> measurements 
> > >>> across entities that carry multiple traffic classes are 
> > >>> meaningless. Of the three entities mentioned in these 
> > >>>> - while measurement accuracy is certainly an important 
> concern, 
> > >>>> it seems
> > >>>>   the draft speaks at the system level; it's of course 
> true that 
> > >>>> within
> > >>>>   to QoS and this is already due for update.  The 
> short version 
> > >>>> is that
> > >>>>   Y.1731-style approaches are complementary.  We would 
> therefore 
> > >>>> expect
> > >>>>>  associated bi-directional LSPs)  3. The problem becomes even 
> > >>>>> more interesting for MPLS-TP
> > >>> Sections:

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 10 Nov 2009 12:55:21 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: dinsdag 10 november 2009 4:57
To: Dan Frost; Stewart Bryant
Cc: [email-masked]
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.

My 2c,
     Sasha

> > delivered user packets to the total number of the user packets over 
> > a specified interval
> > very much in place  5. Comparison with the techniques developed by 
> > in the IPPM
> WG (e.g., RFC
> > associated bi-directional LSPs)  3. The problem becomes even more 
> > interesting for MPLS-TP Sections:
> >
> > Y.1731 (02/08), which explicitly states that these measurements must 
> > take into account only what it calls "in-profile" user traffic.
> >

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 10 Nov 2009 13:10:15 +0100

Sasha,
 
If you look at a service instance, then in this example this service
instance will have its service MEP functions on the ingress port at the left
side in node A and on the egress port at the rigth side in node C. The
service instance MEPs on A and C are counting the packets/frames with a
specific priority value and for which drop eligible is false. MEP on A will
do this for the frames/packets (with Priority X and DropEligible=false)
arriving at its input port, MEP on C will do this for the frames/packet
(with Priority X and DropEligible=false) delivered to its output port. Any
loss of frames/packets with priority X and DropEligible False between the
two MEPs has to be counted as lost frames/packets.
 
For the case of a tunnel instance with its tunnel MEP functions located on
the NNI ports (right side of A and left side of C), then the tunnel MEP is
located functionally before the physical link with its queues. Any drop of
packets with Priority X and Drop Eligible False in the queues in A or B is
counted as lost packet for the tunnel between A and C.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: dinsdag 10 november 2009 5:21
To: Dan Frost; Stewart Bryant
Cc: [email-masked]
Subject: [mpls-tp] What constitutes a transmitted packet (was: Concerns
regarding draft-frost-mpls-tp-loss-delay-00)

Dan, Stewart and all,
I've added Yoshinori to the CC list, because this email has been triggered b
the discussion of
draft-koike-ietf-mpls-tp-oam-maintenance-points-00 at the MPLS WG session
yesterday.

The point I'd like to raise refers to the following definition  that appears
both in the MPLS-TP OAM
requirements draft and id draft-frost-mpls-tp-loss-delay:

<quote>
   The number of user packets not delivered is the difference between the
number of user packets
   transmitted by an End Point and the number of user packets received at an
End Point.
<end quote>

The entity hat is monitored for packet loss has its source EP in Router A,
crosses Router  and has its sink in Router C.
(I say "entity" instead of "LSP" or "PW" because, as we have already agreed,
packet loss measurements apply to a certain CoS and drop precedence level
within these).
 
If the link BC is congested, and some packets belonging to the monitored
entity are dropped due to congestion there, they will be clearly counted as
"user packets not delivered".
 
But what happens if the link AB is congested, and some packets belonging to
the monitored enmity are dropped due to congestion at this point? These
packets are not transmitted in the direct sense of this word, since they
never touch the wire. But neither are they delivered.
 
One could possibly argue that, in transport networks, packets with lowest
drop precedence level should not be dropped due to congestion. But IMHO this
would mean that the packet loss measurement tool, in addition to being quite
complex, would only yield meaningful results in the situations that do not
require any OAM tools (because everything works OK).

My 2c again,
     Sasha

> From: Dan Frost [ <mailto:[email-masked]> mailto:[email-masked]]
> concern, it seems
> therefore expect

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 15:12:43 +0200

Maarten,
I fully agree that your definition makes sense, i.e., a user frame/packet that should have been be transmitted but has been dropped instead due to local congestion is a user frame/packet that has not been delivered.

My issue has been with the wording of the definition in the MPLS-TP OAM requirements draft which explicitly refers to the number of "transmitted" frames/packets as the basis for computing the number of frames/packets that have not been delivered.

Hopefully this note clarifies my position.

Regards,
     Sasha

________________________________
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, November 10, 2009 2:10 PM
To: Alexander Vainshtein; 'Dan Frost'; 'Stewart Bryant'
Cc: [email-masked]
Subject: RE: [mpls-tp] What constitutes a transmitted packet (was: Concerns regarding draft-frost-mpls-tp-loss-delay-00)

Sasha,

If you look at a service instance, then in this example this service instance will have its service MEP functions on the ingress port at the left side in node A and on the egress port at the rigth side in node C. The service instance MEPs on A and C are counting the packets/frames with a specific priority value and for which drop eligible is false. MEP on A will do this for the frames/packets (with Priority X and DropEligible=false) arriving at its input port, MEP on C will do this for the frames/packet (with Priority X and DropEligible=false) delivered to its output port. Any loss of frames/packets with priority X and DropEligible False between the two MEPs has to be counted as lost frames/packets.

For the case of a tunnel instance with its tunnel MEP functions located on the NNI ports (right side of A and left side of C), then the tunnel MEP is located functionally before the physical link with its queues. Any drop of packets with Priority X and Drop Eligible False in the queues in A or B is counted as lost packet for the tunnel between A and C.

Regards,
Maarten

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: dinsdag 10 november 2009 5:21
To: Dan Frost; Stewart Bryant
Cc: [email-masked]
Subject: [mpls-tp] What constitutes a transmitted packet (was: Concerns regarding draft-frost-mpls-tp-loss-delay-00)

Dan, Stewart and all,

<quote>

My 2c again,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 15:23:48 +0200

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

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Tuesday, November 10, 2009 1:55 PM
> To: [email-masked]
> requirements
> measurements across
> >   consideration; that this profile cannot span multiple QoS 
> classes; 
> > and

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 10 Nov 2009 16:38:52 +0100

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:[email-masked]] 
Sent: dinsdag 10 november 2009 14:24
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

- 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

> 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.
> 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.
> 
> 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
> 
> discussion (as it has been recorded by Dan) is that the requirements 
> posted in Section 2.2.11 and, presumably, 2.2.12 of
> 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 
> =

---

From: Phil Bedard <[email-masked]>
Date: Tue, 10 Nov 2009 10:59:29 -0500

I would agree limiting a section to a single traffic class would not  
work in a scalable packet network, and it's not a realistic option.   
However, for a "transport" LSP I would expect it to carry only a  
single CoS.  As an operator, for a transport circuit, I want to be  
agnostic to the underlying data the client is sending.  The CoS is  
determined by the SLA I have with the client, and all traffic is  
treated the same based on that SLA.

Under our current specifications an EPL "port-mode" service can only  
have one CoS, it's a transparent service.  We do not interpret  
customer QoS markings and punt them up to the top label.  We ARE  
currently using E-LSPs to deliver the end to end service, for  
scalability reasons.  However we are looking at demultiplexing this  
traffic into L-LSPs for better insight into each traffic class across  
the network and to provide better protection for higher priority  
services through preemption, the ability to not use protection for  
certain classes, etc.  Traffic can still be differentiated through the  
use of L-LSP drop precedence, and I would agree loss measurement  
should only be based on in-profile traffic.

There are issues though.  Restricting to only L-LSPs would preclude an  
operator from taking multiple clients of different class and using an  
E-EXP based transport LSP, which I could see as something operators  
would want for scale and simplicity reasons.  You would need to build  
a separate transport LSP per CoS and have a function to map the client  
to a specific LSP at tunnel ingress.  I'm okay with that, others may  
not be.

Phil

On Nov 10, 2009, at 2:56 AM, Alexander Vainshtein wrote:

> ready to replace a single PW with multiple (one per traffic class)  
> instances just to be able to say that they
>>>>>> classes; and

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Nov 2009 18:13:43 +0200

Phil,
Lots of thanks for a very important and clearly stated input.

If more operators were to follow your example and to become active on this list,
it would make the process much more effective IMHO.

I would like to clarify one specific point with you.

I assume that, even in the "port-based EPL mode" you apply ingress policing to the customer
traffic and reflect its results in the EXP bits of the top label. (If this assumption is wrong, just say so.)

What would you expect if you were submitting your transport LSP as a client to another operator
acting as the Carrier's Carrier? Would you expect *his* drop precedence levels (as set in *his* top label EXP bits)
to reflect ones you've encoded in *your* EXP bits? (Sorry, I should always say TC/EXP to be politically
correct:-). And if yes, how would it be different from *your* edge device taking into account the QoS
marks set by *your* customer?

Regards, and lots of thanks in advance,
     Sasha

> From: Phil Bedard [mailto:[email-masked]]
> Sent: Tuesday, November 10, 2009 5:59 PM
> To: Alexander Vainshtein
> Cc: [email-masked]; [email-masked]
> traffic class
> > unless you propose to carry each TC
> > on its own fiber (or lambda). This sounds to me like making
> MPLS-TP

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 16:22:23 -0000

Good to see another operator view largely reflecting what I said
earlier.  The deeper reasons for requiring transparency are in G.800
considerations, but there are many practical problems one will 'discover
at leisure' if one ignores this point on transparency.

You may have heard me talk about 'performance isolation' in some prior
mails, and this is simply another manifestation of what transparency
really means.  Here, it is practically the observation that if I am a
customer of some server layer transport network supplier X, then I do
not want the traffic behaviour of any other customer of supplier X to
impact the SLA I have with supplier X....seems obvious, but you can't
achieve this unless:
-	supplier X uses proper connections (necessary condition)
-	supplier X is not overbooking resources (full sufficiency
condition...if the suppliers does gamble on overbooking, then he needs
to keep a close eye on client traffic correlation).

The co-cs mode always does the above, the co-ps mode needs conscious
engineering to do so.  The detail is in G.800, but in essence it is the
difference between regular and irregular time-slices respectively (wrt
both start epoch (their 'forwarding label') and duration (their resource
demand)).

regards, neil

> [mailto:[email-masked]] On Behalf Of Phil Bedard
> Sent: 10 November 2009 15:59
> To: Alexander Vainshtein
> Cc: [email-masked]
> OAMrequirements draft?
> However, for a "transport" LSP I would expect it to carry 
> only a single CoS.  As an operator, for a transport circuit, 
> I want to be agnostic to the underlying data the client is 
> sending.  The CoS is determined by the SLA I have with the 
> client, and all traffic is treated the same based on that SLA.
> 
> Under our current specifications an EPL "port-mode" service 
> can only have one CoS, it's a transparent service.  We do not 
> interpret customer QoS markings and punt them up to the top 
> label.  We ARE currently using E-LSPs to deliver the end to 
> end service, for scalability reasons.  However we are looking 
> at demultiplexing this traffic into L-LSPs for better insight 
> into each traffic class across the network and to provide 
> better protection for higher priority services through 
> preemption, the ability to not use protection for certain 
> classes, etc.  Traffic can still be differentiated through 
> the use of L-LSP drop precedence, and I would agree loss 
> measurement should only be based on in-profile traffic.
> 
> There are issues though.  Restricting to only L-LSPs would 
> preclude an operator from taking multiple clients of 
> different class and using an E-EXP based transport LSP, which 
> I could see as something operators would want for scale and 
> simplicity reasons.  You would need to build a separate 
> transport LSP per CoS and have a function to map the client 
> to a specific LSP at tunnel ingress.  I'm okay with that, 
> others may not be.
> 
> 
> Phil
> 
> 
> 
> 
> > As I have said, the implications for scalability would be 
> destructive 
> > IMHO.
> >
> > unless you propose to carry each TC on its own fiber (or 
> lambda). This 
> > sounds to me like making MPLS-TP undeployable, but you 
> should ask the 
> > operators on the list.
> >
> > And, to the best of my knowledge, Ethernet PWs carry 
> multiple traffic 
> > classes today, and, in this way have been successfully deployed as 
> > Ethernet Services by transport operators all over the world.
> > Again, I would be happy to hear, what the transport 
> operators have to 
> > say about that, namely, are they ready to replace a single PW with 
> > multiple (one per traffic class) instances just to be able 
> to say that 
> > they can now measure packet loss per PW?
> >
> > Regards,
> >     Sasha
> >
> >>>>>> it seems  best addressed at the equipment/implementation spec
> >>>> level in this
> >>>>>>  case.
> >>>>>> within  a distributed system the clocks of the tx/rx 
> cards must 
> >>>>>> be  synchronized; this can be clarified.  In general we can
> >>>>> elaborate on
> >>>>>> - 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 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
> >>>>>>> loss measurement across multiple classes of service 
> makes  any 
> >>>>>>> sense whatsoever
> >>>>>>> for which this measurement is performed - which, of 
> course,  is 
> >>>>>>> broken with E-LSPs
> >>>>>>> *

---

From: Phil Bedard <[email-masked]>
Date: Tue, 10 Nov 2009 11:46:21 -0500

Answers inline.

On Nov 10, 2009, at 11:13 AM, Alexander Vainshtein wrote:

> traffic and reflect its results in the EXP bits of the top label.  
> (If this assumption is wrong, just say so.)

We do police, but we simplify this by creating a fixed bandwidth  
service, CIR=PIR, minus a small amount of buffering for microbursts,  
but those are still considered in-profile.  It's difficult to support  
burstable services on a transport-like network.  I know however this  
is important for many operators and there should be a mechanism within  
an L-LSP like drop precedence or DE to differentiate between in- 
profile and out-of-profile traffic.  Treating all client frames  
equally does not lead to ultimate efficiency, not what you would get  
from differentiating client frames on ingress and marking down what's  
not important to the customer.  It's still a packet based network  
though, and on egress queueing I'm still comparing packets for  
priority and can drop ones of lower priority, whether it's an E-LSP or  
L-LSP.  The priority is based on an agreed upon SLA with the customer.

> acting as the Carrier's Carrier? Would you expect *his* drop  
> precedence levels (as set in *his* top label EXP bits)
> marks

I would not expect his TC/EXP bits to reflect mine.  I know in most  
cases I've seen an operator will only honor my markings for ingress  
and egress queuing, not for differentiation on their backbone/ 
transport network.  I think you'll find most carriers do not have  
similar QoS schema.  What they mark the traffic as across their  
network is based on a SLA we agree upon.  He needs to engineer his  
network to provide the protection/performance I'm paying for.  I do  
not necessarily care how that gets done, as long as it is done.

>> preclude an
>>> destructive IMHO.
>>>>>>>> synthetic and

---

From: "Riccardo Martinotti" <[email-masked]>
Date: Tue, 10 Nov 2009 20:12:37 +0100

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: [email-masked] per conto di Maarten Vissers
Inviato: mar 10/11/2009 16.38
A: 'Alexander Vainshtein'
Cc: [email-masked]
Oggetto: Re: [mpls-tp] Impossible requirements in the MPLS-TP OAM requirements draft? (was: Concerns regarding draft-frost-mpls-tp-loss-delay-00)

Sasha,

Option A
========

Option B
========

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 10 november 2009 14:24
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

Regards,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 10 Nov 2009 21:29:45 +0100

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:[email-masked]] 
Sent: dinsdag 10 november 2009 20:13
To: Maarten Vissers; Alexander Vainshtein
Cc: [email-masked]
Subject: R: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

Regards,

Riccardo

Oggetto: Re: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Sasha,

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)

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

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 10 november 2009 14:24
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Nov 2009 02:35:00 +0200

Phil,
Again, lots of thanks for an important input.

My reading of your answers is that you do not have any Discard Eligible packets in your transport network
(you discard them at the edge).

This definitely makes things simpler. Personally I would be happy to hear from the other
operators on this list if this other models you've mentioned are also...

Regards,
     Sasha

> Sent: Tuesday, November 10, 2009 6:46 PM
> To: Alexander Vainshtein
> > What would you expect if you were submitting your transport
> LSP as a
> > client to another operator
> > to reflect ones you've encoded in *your* EXP bits? (Sorry,
> I should
> > always say TC/EXP to be politically
> others may

---

From: "Riccardo Martinotti" <[email-masked]>
Date: Wed, 11 Nov 2009 10:14:38 +0100

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:[email-masked]] 
Sent: martedì 10 novembre 2009 21.30
To: Riccardo Martinotti
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM requirements draft? (was: Concerns regarding draft-frost-mpls-tp-loss-delay-00)

Ricardo,

Regards,
Maarten

-----Original Message-----
From: Riccardo Martinotti [mailto:[email-masked]] 
Sent: dinsdag 10 november 2009 20:13
To: Maarten Vissers; Alexander Vainshtein
Cc: [email-masked]
Subject: R: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

Regards,

Riccardo

Sasha,

Option A
========

Option B
========

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 10 november 2009 14:24
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

Regards,
     Sasha

---

From: Phil Bedard <[email-masked]>
Date: Wed, 11 Nov 2009 09:45:38 -0500

The packets which are discard eligible in the core are from lower SLA  
services.  You are correct in saying no single service has both in- 
profile and out-of-profile packets.  We use the same MPLS-based  
transport network for circuit emulation as we do best-effort Internet  
service, it's all carried via pseudowires.  A best-effort service is  
out-of-profile by default.   Using a single CoS for a service makes it  
easier to keep track of bandwidth for CAC, otherwise you would need to  
keep track of CIR per class per service.  Not that it cannot be done  
through a good NMS.   To steal part of one of Maarten's post, the CIR  
services cannot exceed a port capacity.  Interestingly enough, the  
equipment vendor we use is moving from Maarten's B implementation to  
an A implementation.  From one where all EIR is treated the same to  
one where some EIR is preferred over other EIR.   If you use the  
below, we do not have a Queue 3 today.  Traffic is either guaranteed  
or it's not, and guaranteed is not oversubscribed.

Quote Maarten's post below
-------------------------------------------------
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
========

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.

Phil

On Nov 10, 2009, at 7:35 PM, Alexander Vainshtein wrote:

> My reading of your answers is that you do not have any Discard  
> Eligible packets in your transport network

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 15:53:30 -0000

One question Phil.  Are you using proper connections, ie RSVP-TE?

regards, Neil 

> Sent: 11 November 2009 14:46
> To: Alexander Vainshtein
> Cc: [email-masked]
> The packets which are discard eligible in the core are from 
> lower SLA services.  You are correct in saying no single 
> service has both in- profile and out-of-profile packets.  We 
> use the same MPLS-based transport network for circuit 
> emulation as we do best-effort Internet service, it's all 
> carried via pseudowires.  A best-effort service is  
> easier to keep track of bandwidth for CAC, otherwise you 
> would need to keep track of CIR per class per service.  Not 
> that it cannot be done  
> services cannot exceed a port capacity.  Interestingly 
> enough, the equipment vendor we use is moving from Maarten's 
> B implementation to an A implementation.  From one where all 
> EIR is treated the same to  
> below, we do not have a Queue 3 today.  Traffic is either 
> guaranteed or it's not, and guaranteed is not oversubscribed.
> 
> 
> Queue 2: premium, real time traffic (CIR only) Queue 3: 
> medium (CIR + EIR) Queue 4: best effort (EIR only)
> 
> Option B
> ========
> Queue 2: premium, real time traffic (CIR only) Queue 3: 
> medium (CIR part) Queue 4: medium (EIR part) + best effort (EIR only)
> 
> For option A this implies that the EIR of the medium CoS has 
> priority over the EIR of the best effort CoS.
> > Eligible packets in your transport network (you discard them at the 
> > edge).
> >
> > This definitely makes things simpler. Personally I would be 
> happy to 
> > hear from the other operators on this list if this other 
> models you've 
> > mentioned are also...
> >
> > Regards,
> >     Sasha
> >
> >
> >>> I assume that, even in the "port-based EPL mode" you 
> apply ingress 
> >>> policing to the customer traffic and reflect its results 
> in the EXP 
> >>> bits of the top label.
> >> is important for many operators and there should be a mechanism 
> >> within an L-LSP like drop precedence or DE to 
> differentiate between 
> >> in- profile and out-of-profile traffic.  Treating all 
> client frames 
> >> priority and can drop ones of lower priority, whether it's 
> an E-LSP 
> >> or L-LSP.  The priority is based on an agreed upon SLA with the 
> >> customer.
> >>
> >>>
> >>> precedence levels (as set in *his* top label EXP bits) to reflect 
> >>> ones you've encoded in *your* EXP bits? (Sorry,
> >> I should
> >>> correct:-). And if yes, how would it be different from 
> *your* edge 
> >>> device taking into account the QoS marks
> >>
> >>>> traffic into L-LSPs for better insight into each traffic class 
> >>>> across the network and to provide better protection for higher 
> >>>> priority services through preemption, the ability to not use 
> >>>> protection for certain classes, etc.  Traffic can still be 
> >>>> differentiated through the use of L-LSP drop precedence, and I 
> >>>> would agree loss measurement should only be based on in-profile 
> >>>> traffic.
> >>>>
> >>>> There are issues though.  Restricting to only L-LSPs 
> would preclude 
> >>>> an operator from taking multiple clients of different class and 
> >>>> using an E-EXP based transport LSP, which I could see as 
> something 
> >>>> operators would want for scale and simplicity reasons.  
> You would 
> >>>> need to build a separate transport LSP per CoS and have 
> a function 
> >>>> to map the client to a specific LSP at tunnel ingress.  I'm okay 
> >>>> with that,
> >> others may
> >>>> not be.
> >>>>
> >>>>
> >>>> Phil
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> You can restrict MPLS-TP to supporting only L-LSPs by 
> changing the 
> >>>>> MPLS-TP framework draft.
> >>>>> unless you propose to carry each TC on its own fiber 
> (or lambda). 
> >>>>> This sounds to me like making
> >>>> MPLS-TP
> >>>>> traffic classes today, and, in this way have been successfully 
> >>>>> deployed as Ethernet Services by transport operators 
> all over the 
> >>>>> world.
> operators have 
> >>>>> to say about that, namely, are they ready to replace a 
> single PW 
> >>>>> with multiple (one per traffic class) instances just to 
> be able to 
> >>>>> say that they can now measure packet loss per PW?
> >>>>>
> >>>>> Regards,
> >>>>>   Sasha
> >>>>>
> >>>>>> If MPLS-TP is used in a transport network it should carry only 
> >>>>>> one class of service (as Neil pointed out as well).
> shepherd of 
> >>>>>>>>> the same draft) and Adrian to the CC list.
> >>>>>>>>>
> >>>>>>>>> of our discussion (as it has been recorded by Dan) 
> is that the 
> >>>>>>>>>> concern, it seems best addressed at the 
> >>>>>>>>>> equipment/implementation spec
> >>>>>>>> level in this
> >>>>>>>>>> case.
> >>>>>>>>>> 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
> >>>>>>>>>> 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

---

From: Phil Bedard <[email-masked]>
Date: Wed, 11 Nov 2009 11:13:19 -0500

Yes, we are using RSVP-TE in both the access and the core of the  
network, and all traffic is carried in those tunnels.  There is no LDP  
on the network.

Phil

---

From: <[email-masked]>
Date: Wed, 11 Nov 2009 16:15:49 -0000

Thanks Phil....yes, it would be a little "challenging" to use LDP...just
wanted to be sure however.

regards, Neil 

> Sent: 11 November 2009 16:13
> To: Harrison,N,Neil,DEY2 R
> Cc: [email-masked]; [email-masked]
> Yes, we are using RSVP-TE in both the access and the core of 
> the network, and all traffic is carried in those tunnels.  
> There is no LDP on the network.
> 
> Phil
> 
> would need 
> >> to keep track of CIR per class per service.  Not that it cannot be 
> >> done
> >> Queue 1: network control & management traffic (CIR only) Queue 2: 
> >> premium, real time traffic (CIR only) Queue 3:
> >> Queue 1: network control & management traffic (CIR only) Queue 2: 
> >> premium, real time traffic (CIR only) Queue 3:
> >> Reading from the queues is by means of strict priority, 
> with order of 
> >> 1
> >> over the EIR of the best effort CoS.
> to reflect 
> >>>>> always say TC/EXP to be politically correct:-). And if yes, how 
> >>>>> would it be different from
> >> *your* edge
> successfully 
> >>>>>>>>>>>>> to share them with you and the list prior to 
> discussion at
> >>>>>>>>>>>> the MPLS-TP
> >>>>>>>>>>>>> Hiroshima sessions.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> measurements, the specification of desired and 
> achievable
> >>>>>>>>>>>> accuracy of
> >>>>>>>>>>>>> measurements, the wall clock at the two end 
> points of the
> >>>>>>>>>>>> measurement
> >>>>>>>>>>>>> 3. What the draft does not mention that, even 
> in the case
> >>>>>>>>>>>> of two-way
> >>>>>>>>>>>>> 1. The MPLS-TP framework draft explicitly 
> states that both
> >>>>>>>>>>>> E-LSPs and
> >>>>>>>>>>>>> consideration multiple CoS (where applicable) 
> and multiple
> >>>>>>>>>>>> precedence

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 12 Nov 2009 16:22:59 +0100

Riccardo,

See inline...

-----Original Message-----
From: Riccardo Martinotti [mailto:[email-masked]] 
Sent: woensdag 11 november 2009 10:15
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM

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

[mv] Correct.

How do I treat "CIR and EIR flows" in this case? Usually the bandwidth
profile enforcement functions foresee a dual token bucket. 

[mv] If you want to support a flow of which X% could be CIR and 100-X% is
EIR, then you need to use Option A.

[mv] Note that Option A and Option B methods can be used in one network;
i.e. you could mix both methods. The Traffic Conditioning function at the
ingress port of the network classifies and marks each incoming frame/packet.
A service X can be classified/marked using Option A CoS #3; i.e. the
frames/packet will be carrying either Priority_C/Non_Drop_Eligible, or
Priority_C/Drop_Eligible indications. A service Y can be classified/marked
using Option B CoS #3; i.e. the frames/packet will be carrying either
Priority_C/Non_Drop_Eligible, or Priority_D/Drop_Eligible indications.

[mv] At the input of each of the NNI physical links we will have the 4
Queues. Option A CoS #3 packets will all be going through Queue_3. Option B
CoS #3 packets will be going through either Queue_3 or Queue_4, under
control of their priority indication (C or D).

[mv] If there is a common understanding that Option A is better and
preferred, then it would be helpful to specify this Option. Having to
support only a single option is less complex then having to support more
then one option.

Regards,
Riccardo

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: martedì 10 novembre 2009 21.30
To: Riccardo Martinotti
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Ricardo,

Regards,
Maarten

-----Original Message-----
From: Riccardo Martinotti [mailto:[email-masked]]
Sent: dinsdag 10 november 2009 20:13
To: Maarten Vissers; Alexander Vainshtein
Cc: [email-masked]
Subject: R: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

Regards,

Riccardo

Sasha,

Option A
========

Option B
========

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 10 november 2009 14:24
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Impossible requirements in the MPLS-TP OAM

Maarten,

Regards,
     Sasha