Subject: [mpls-tp] PHB on CC-V OAM packets

From: "Annamaria Fulignoli" <[email-masked]>
Date: Thu, 11 Mar 2010 11:29:58 +0100

Hi all,

in draft-ietf-mpls-tp-oam-framework-05, section 5.1 is reported: 
"Proactive CC-V OAM packets are transmitted with the "minimum loss
probability PHB" within a single network operator. This PHB is
configurable on network operator's basis. ..........."

In my opinion, that could be not applicable in some cases as, for
instance, in case of L-LSPs with different PHB .
I think that it should also be possible to transmit proactive CC-V OAM
packets with the "minimum loss probability PHB" within the transport
entity (LSP, PW) they are monitoring .

Thanks and Kind Regards,
Annamaria

---

From: David Allan I <[email-masked]>
Date: Fri, 12 Mar 2010 07:26:55 -0500

Hi Annamaria:

We'll improve the text in the next version

thanks for the catch
D

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Annamaria Fulignoli
Sent: Thursday, March 11, 2010 5:30 AM
To: [email-masked]
Subject: [mpls-tp] PHB on CC-V OAM packets

Hi all,

in draft-ietf-mpls-tp-oam-framework-05, section 5.1 is reported:
"Proactive CC-V OAM packets are transmitted with the "minimum loss probability PHB" within a single network operator. This PHB is configurable on network operator's basis. ..........."

In my opinion, that could be not applicable in some cases as, for instance, in case of L-LSPs with different PHB .
I think that it should also be possible to transmit proactive CC-V OAM packets with the "minimum loss probability PHB" within the transport entity (LSP, PW) they are monitoring .

Thanks and Kind Regards,
Annamaria

---

From: John E Drake <[email-masked]>
Date: Fri, 12 Mar 2010 06:10:39 -0800

What does that do to fate sharing?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Allan I
> Sent: Friday, March 12, 2010 4:27 AM
> To: Annamaria Fulignoli; [email-masked]
> Subject: Re: [mpls-tp] PHB on CC-V OAM packets
> 
> Hi Annamaria:
>

---

From: <[email-masked]>
Date: Fri, 12 Mar 2010 15:05:27 -0000

John,

If you recall my previous observations on what is THE fundamental
service that a transport network must provide to its clients it is
transparency.  This demands several behaviours need to be respected:

-	The server layer network must make no attempt to understand, and
for sure not change, the nature of the client traffic units (a client
traffic unit is larger information symbol built from the atomic bit
information symbol).

-	This implies there must be no attempt to judge either importance
or temporal urgency of the client symbols by the server layer  (in fact,
this information is only known in the very top-of-stack layer network,
which may not be the immediate client of the server layer, that holds
the external message/file/stream adaptation functions).

-	This also implies that all client symbols preserve their
ordering (in a connection).

-	This also implies there can be no QoS (sic) classes in a
connection.....or in the parlance of the mail thread below, there cannot
be multiple PHBs in a transport network connection.

-	And for full transparency sufficiency, the traffic behaviour of
client X must not impact the performance/SLA enjoyed by client
Y.....this implies no server layer resource overbooking.

Aside=> Of course one can ignore all this.  But please be aware that
there will be practical problems downstream if one does.  For example,
if there are multiple QoS/PHBs in a single transport connection there
will be difficulties in defining the entry/exit criteria for
unavailability...and if there is one parameter one must get right in a
transport network it is availability.

So these are the behaviours that must be met if one wishes to claim a
transport network behaviour from a co-ps mode network....noting that all
the above are default (and cannot be compromised anyway) in the co-cs
mode.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John E Drake
> Sent: 12 March 2010 14:11
> To: David Allan I; Annamaria Fulignoli; [email-masked]
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of David Allan I
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: John E Drake <[email-masked]>
Date: Fri, 12 Mar 2010 07:25:19 -0800

Neil,

You and I had this discussion about 3-4 years ago, and the conclusion we reached was that an E-LSP (That's the one that has multiple PHBs, right?) was actually eight parallel LSPs, with the label for a given packet being the concatenation of the E-LSP label and the traffic class.

For OAM, I think this means that all PHBs within the E-LSP need to be exercised.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 12, 2010 7:05 AM
> To: John E Drake; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [mpls-tp] PHB on CC-V OAM packets
> 
> John,
> 
> > > Behalf Of Annamaria Fulignoli

---

From: <[email-masked]>
Date: Fri, 12 Mar 2010 15:38:55 -0000

I do recall this John....and my response was not for you per se, but as
a general warning of where this looks like heading. 

If one does not have proper connections (LDP/PHP/ECMP all wreck this)
then worrying about availability/performance is somewhat moot anyway.
If one does have proper connections, which is a necessary but not
sufficient requirement for a transport network, then one can start to
think more seriously about availability/performance matters.  However,
given the transparency requirement that must be met (as per prior
comments below) then a *single connection* must not have multiple QoS
(sic) classes within that connection.  So in MPLS-TP, if this is to be
regarded as a transport network role there cannot be such things as
E-LSPs.

regards, Neil   

> From: John E Drake [mailto:[email-masked]] 
> Sent: 12 March 2010 15:25
> To: Harrison,N,Neil,DKQ7 R; [email-masked]; 
> You and I had this discussion about 3-4 years ago, and the 
> conclusion we reached was that an E-LSP (That's the one that 
> has multiple PHBs, right?) was actually eight parallel LSPs, 
> with the label for a given packet being the concatenation of 
> the E-LSP label and the traffic class.
> 
> > or temporal urgency of the client symbols by the server layer  (in 
> > fact, this information is only known in the very top-of-stack layer 
> > network, which may not be the immediate client of the server layer, 
> > that holds the external message/file/stream adaptation functions).
> > 
> > connection.....or in the parlance of the mail thread below, there 
> > cannot be multiple PHBs in a transport network connection.
> > 
> > transport network behaviour from a co-ps mode 
> network....noting that 
> > all the above are default (and cannot be compromised anyway) in the 
> > co-cs mode.
> > 
> > regards, Neil
> > 
> [mailto:[email-masked]] 
> > > > On Behalf Of David Allan I
> [mailto:[email-masked]] 
> > > > On Behalf Of Annamaria Fulignoli

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 12 Mar 2010 10:20:33 -0800

Dear Neil,
greatly appreciate your opinion and would second Tom's call to you to write
a document, at least for the sake of recording it.
Your concerns whether MPLS-TP, as being defined by IETF, is compliant to be
considered a packet transport network reminded me of changes to one of
MPLS-TP framework documents made by ITU (believe it was by Malcolm). Quite
consistently, all references to "transport" in regard to MPLS-TP were were
deleted leaving MPLS-TP as "packet network". And sentence stating that
packet transport solution is set of MPLS-TP functionality selected by ITU-T
(not to the letter but that was the idea). If my recollection is correct,
then perhaps IETF's MPLS-TP is not the packet transport and we need to move
to ITU-based discussion.

Regards,
Greg