Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements)

From: "Drake, John E" <[email-masked]>
Date: Sat, 18 Apr 2009 14:01:05 -0700

Maarten,

Italo claims TCM is a functional requirement of G.805.  You claim it is a more efficient solution to something, I'm not sure what, than LSP hierarchy.  I am beginning to suspect that TCM is a desert topping and a floor wax.

Thanks,

John
John Drake
Boeing Satellite Systems
2260 East Imperial Highway MC W-S05-P208
El Segundo, CA 90245
[email-masked]
(412) 370-3108

----- Original Message -----
From: Maarten Vissers <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: 'MPLS-TP' <[email-masked]>
Sent: Sat Apr 18 10:20:12 2009
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectional transport path requirements)

Xueqin,

The nested LSP is a more complex solution then TCM. TCM just requires the
activation of some MEPs in the LSP. Nested LSP requires to set up the same
MEP functions plus set up an additional LSP and change the existing LSP.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Xueqin WEI (Shuetsing WEI)
Sent: zaterdag 18 april 2009 8:52
To: Ben Niven-Jenkins
Cc: MPLS-TP
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was
RE:Associatedbidirectional transport path requirements)

Support, I think the nested LSP will be great! Until now, I didn't see any
difference between the nested LSP and TCM on performance monitoring. But the
nested LSP will make the things more easy. I would like select a simple way
to resolve the problem.

Sincerely Yours
Xueqin Wei (Shuetsing Wei)

Fiberhome Telecommunication Technologies Co.,Ltd.,
2009-04-18  14:48:51

==================== Following is your email=====================
Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:
Associatedbidirectional transport path requirements)
Sent：2009-04-17 17:17:31
From:Ben Niven-Jenkins
To:BUSI ITALO; Adrian Farrel; Alexander Vainshtein CC to:mpls-tp

>Italo,
>
>On 17/04/2009 09:34, "BUSI ITALO" <[email-masked]> wrote:
>> The JWT agreement is to bring the ITU-T transport requirements in 
>> IETF to extend the MPLS architecture to meet them in a way that is 
>> compatible, consistent and coherent with existing IETF architecture.
>
>So I took a look at the JWT report. It says (slide 16)
>
>" Service Providers want LSPs/PWEs to be able to be managed at the 
>different nested levels seamlessly (path, segment, multiple segments)
>    aka Tandem Connection Monitoring (TCM), this is used for example 
>when a LSP/PWE crosses multiple administrations"
>
>IMO the requirement is to be able to monitor parts of a path as well as 
>the end to end path. There are many ways to solve that requirement, one 
>of which is the creation of nested LSPs, one per level of monitoring 
>required (my understanding of how TCM works).
>
>I think the real discussion is therefore is the requirement to monitor 
>different components of an end to end path or is the requirement that 
>such monitoring MUST be achieved using nested LSPs?
>
>As an example PW technology today allows end to end and per segment 
>monitoring but it does not achieve it using nested PWs or PW levels.
>
>Ben
>
>_______________________________________________
>mpls-tp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls-tp
>

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

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

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 18 Apr 2009 23:18:28 +0200

Hi John,

You wrote:

> Italo claims TCM is a functional requirement of G.805.
 > You claim it is a more efficient solution to something,
 > I'm not sure what, than LSP hierarchy.  I am beginning to
 > suspect that TCM is a desert topping and a floor wax.

Do you mean it is a tool that serves two purposes.
In that case it minimizes the toolset.

Cheers, Huub.

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

---

From: <[email-masked]>
Date: Sun, 19 Apr 2009 08:23:14 +0100

I think it’s a tool Huub that is unncessary and creates complications/costs for no good reason....just like peer interworking of non top-of-stack networks does too.  I have already explained why BT does not want to waste our time/money on these topics, but I will happily go over the logic as many times as it takes for our suppliers to grasp this.

In the meantime have a think about these questions:

How come the Internet has done great without it...and I don't see IETF asking for it?
How come the PSTN has done great without it?
How come our Ops guys are not asking for it ....esp given the TCM idea has been around for a very long time? 

I think this is more of a job/work creation scheme based on a flawed vision of where networking needs to go.  If you really want to create a good vision for future networking direction you must start with the physics that G.800 lays down (because these are the real truths based on a solid underpinning of Info/Systems Theory of networking) coupled with the requirements of real external customers/users of networks.

When you do that you find that 3 major networking planks emerge:
-	there are 3 network modes....and they are *not* the same...each provides something different....so a networking philosophy that does not recognise/understand this and instead seeks to (i) blindly apply the same func components to each (DP OAM is only one component) and (ii) tries to interwork them as peers, is just plain wrong.
-	external applications generate 3 distinct types of information...messages, files and streams......and whilst their QoS (==delay) requirements are generally fixed/invariant per information source type their survivability importance can assume any value in any information source type.
-	there are 2 layer network relationships....client/server and peer-partition....the former is by far the most common/important (esp for private 'network builder' services) whilst the latter is only important for top-of-stack networks that support the external applications (esp in a public service context).

So if you don't have a networking vision that factors-in all these things then you don't actually have a useful vision at all.....indeed such a vision is conspicuously absent in what I see some folks pushing for.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Huub van Helvoort
> Sent: 18 April 2009 22:18
> To: Drake, John E
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP 
> (wasRE:Associatedbidirectional transport path requirements)
> 
> Hi John,
> 
> You wrote:
> 
> > Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP 
> (wasRE:Associatedbidirectional transport path requirements)
> > 
> > Xueqin,
> > 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf