Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2009 11:55:17 +0100

The draft has applicability to Transport.

I will come to the details below in a minute, but tell me how you 
propose to cope with
ESSM in a client - surely you need to intervene rather than carry them 
transparently?

Remember that the client layer performs the classification into protocol 
types
so we just carry the classification over the server layer in a more 
convenient way.

Remember if you don't like the pkt-pw you can always put a real interface in
and use a  L2 pw, and if you don't like that you can always but a clear
fibre. What you do depends on how you wish to run the economics.

[email-masked] wrote:
> Stewart, can I please ask if this draft would be applicable to MPLS-TP?
>  
> I ask this because a transport network should satisfy the requirements 
> of transparency....which in brief means:
>  
> -    all client bits treated equally
That happens here
> -    client bit ordering preserved
That also happens here
> -    no attempt made to try understand semantics of client symbols (ie 
> client message/traffic-unit formed from N client bits) and never 
> change client bits
In this mechanism it is the client layer that makes the changes - not 
the server layer. The client presents the packet and and metadata saying 
what pid the server is to write into the PID
> -    server ensures client X traffic behaviour cannot impact 
> performance experienced by client Y
We pass that test
>  
> ...and I cannot reconcile this with this draft.  So perhaps this draft 
> is only intended to apply to 'classical' MPLS?
It's not clear that it fails the test when you realize that the client 
is presenting the modified data to the server.

Stewart

>  
> regards, Neil
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *BOCCI Matthew
>     *Sent:* 31 March 2009 12:51
>     *To:* [email-masked]
>     *Subject:* [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
>
>     This is the start of a two week poll to judge the consensus to
>     move draft-bryant-filsfils-fat-pw-03
>      to a PWE3 Working Group draft.
>
>     Please can you respond to the PWE3 list with your approval (or
>     otherwise).
>
>     This poll will close on 14th April 2009.
>
>     Regards
>
>     Matthew
>
>

---

From: <[email-masked]>
Date: Wed, 1 Apr 2009 15:27:02 +0100

Thanks Stewart,
 
Stewart answered 01 April 2009 11:55
> ESSM in a client - surely you need to intervene rather than 

NH=> I am not familiar with what you mean by ESSM .....are you meaning
some of the Ethernet 'slow protocols'?...if so then yes, these belong to
a p2p Ethernet section layer only.
> so we just carry the classification over the server layer in a more 

NH=> Normally adaptation to a transport network passes down PID
primitives and (esp for a co-cs server) attends to things like client
traffic unit delineation and idle fill.  One of the things we usually
cannot do (and indeed don't want to do) is try and understand each
specific ultimate application's QoS or (more importantly) survivability
importance semantics....this is of course what a co-cs server does by
'default'....and this becomes of increasing importance when the client
is not a top-of-stack layer network anyway (so one can't even see the
top-level message/file/stream application conversations, and even if we
could we would usually not be in any position to make value judgements
on survivability importance).

If we have a definite IP top-of-stack layer network that we can see then
we can get at the end-end UDP/TCP/RTP adapted applications and thus keep
conversations together.  Now a top-of stack layer network is always
present (has to be, else there is no communication happening), but this
may not be the immediate client, and so may not be easily visible...the
real top-of-stack layer network may be several layers removed from the
immediate client.....so I am thinking of things like when we do
MPLSoverMPLS, where the layers involved here could be something like
this:

Application_UDP/TCP/RTP_IP_MPLSclient_ETH_PW_MPLSserver_X.

It's not at all clear to me that the MPLSserver network should be trying
to figure out the end-end application flows above the MPLSclient
network.  Would you agree with that?

> fibre. What you do depends on how you wish to run the economics.

NH=> Agreed.  But when we start introducing inter-layer functional
dependencies complexity rises.....increasing complexity usually means
rapidly increasing marginal costs with increase in scale/scope of a
system.  This is why you will hear folks like me and Andy Reid talk
about the importance of 'transparency' in client/server relationships,
and esp so for transport networks....its not just important for the
clients but its also important to control complexity costs of the server
(and overall networking system).

I was under the impression that ECMP would not be used in MPLS-TP, but
if MPLS-TP is not supposed to be a emulating a true transport network
then I guess one can do this.

regards, Neil

---

From: "BUSI ITALO" <[email-masked]>
Date: Wed, 1 Apr 2009 17:24:19 +0200

Stewart,

Could you please clarify the applicability of Fat PW to MPLS-TP?

In SF, you stated that they are applicable to "ECMP and LAG case" and
this matched with my understanding of the draft.

Due to the fact that ECMP is not used in MPLS-TP, I had assumed this
draft is not applicable in MPLS-TP.

Did I miss/misunderstand anything?

Thanks, Italo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: Wednesday, April 01, 2009 12:55 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw-03 to WG draft?
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2009 16:35:30 +0100

Actually I should rephrase this.

It is the MEAD team that make recommendations as to what is applicable 
to MPLS-TP,
not the PWE3 WG.

The Packet PW represents a tool that is certainly of use in MPLS 
classic, and
if the MEAD team deem it appropriate may also be used in MPLS-TP.

Stewart

Stewart Bryant wrote:
> Remember that the client layer performs the classification into 
> protocol types
>> I ask this because a transport network should satisfy the 
>> requirements of transparency....which in brief means:
>>  
>> -    no attempt made to try understand semantics of client symbols 
>> (ie client message/traffic-unit formed from N client bits) and never 
>> change client bits
> the server layer. The client presents the packet and and metadata 
> saying what pid the server is to write into the PID
>> ...and I cannot reconcile this with this draft.  So perhaps this 
>> draft is only intended to apply to 'classical' MPLS?

---

From: Lucy Yong <[email-masked]>
Date: Wed, 01 Apr 2009 11:08:20 -0500

Are we mixing different subject together? Title is about flow label but the
text is Packet PW.
Lucy.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
> Sent: Wednesday, April 01, 2009 10:36 AM

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 01 Apr 2009 17:38:42 +0100

Sorry I misread the subject line - that's the problem with having
two drafts running in parallel :)

Pkt PW may apply to MPLS-TP that is a MEAD team call.

Fat PW I assume is only applicable to classic. The only way that
I can see to do LAG in a transport context is to do pw-bonding, otherwise
you violate the ordering.

Sorry for any confusion.

Stewart

BUSI ITALO wrote:
>>> Stewart, can I please ask if this draft would be applicable 
>>>       
>> to MPLS-TP?
>>     
>>>  
>> requirements 
>>> -    no attempt made to try understand semantics of client 
>>>       
>> symbols (ie 
>>     
>>> ...and I cannot reconcile this with this draft.  So perhaps 
>>>       
>> this draft 
>>

---

From: <[email-masked]>
Date: Wed, 1 Apr 2009 17:51:13 +0100

Thanks Stewart....
> Fat PW I assume is only applicable to classic. 

That certainly clears up a key concern I had with FAT PWs and MPLS-TP.

regards, Neil

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: 01 April 2009 17:39
> To: BUSI ITALO
> Cc: Harrison,N,Neil,CXM R; [email-masked]