Subject: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements)

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Apr 2009 14:39:56 +0300

Adrian,

Looks as we are much more in agreement than it could be guessed from the first round of exchanges.

I've changed the subject since we are actually discussing specifics of co-routed bidirectional paths.

I fully support your proposal to get rid (in a consistent manner) from the TC stuff in MPLS-TP, especially since, to the best of my knowledge, operational experience with SONET/SDH TCM (ITU-T definitions notwithstanding) did not prove its worth. If this is based on mis-perception, I would be glad to hear that (especially from the operators on this list).

And if it is possible to re-write Requirement 34 as a functional/behavior requirement, it would be great, too.

However, I am not sure this would be easy (Ben, my apologies again).

Regards,

     Sasha

________________________________________
From: Adrian Farrel [[email-masked]]
Sent: Thursday, April 16, 2009 12:59 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; Lou Berger; BUSI ITALO
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Sasha,

> Unfortunately I cannot fully agree with your statement:
>
> <quote>
>     From the point of view of hardware, co-routed bidirectional LSPs
>     are a special case of associated bidirectional LSPs.
> <end quote>
>
> This statement would be obviously correct, were it not for Requirement 34
> in the latest
> MPLS-TP requirements draft

OK. Got it.

But what is this doing in the data plane requirements section?

In fact, what is this requirement actually saying?

> <quote>
>      The intermediate nodes (including MEPs, MIPs and other internal
>       functions as appropriate) of a co-routed bidirectional transport
>       path at each (sub-)layer MUST be aware of the pairing
>       relationship of the forward and the backward directions of that
>       transport path.
> <end quote>

There is no way this is a functional requirement. That is, there is
*nothing* that can be observed from a black box point of view that results
from adhering to this requirement.

Therefore it could be assumed that this requirement is met by configuring
some data plane database component through the management plane. The
database component is not used for anything except to satisfy this
requirement for "awareness".

Ben! Can we please try to rewrite this requirement in terms of behavior?

> Please note that Requirement 34 is the ONLY item in the list that is
> specific
> for co-routed bidirectional LSPs. (The pairing requirements at end points
> for co-routed and associated bidirectional paths are exactly the same even
> if they appear in two different items in the requirements' list).
> In other words, without Requirement 34 the notion of co-routed
> bidirectional
> paths would be void of any data plane content.
>
> The somewhat vague scope of this requirement ("other internal functions
> as appropriate") creates a suspicion that HW support of the pairing
> awareness
> may be required in order to comply with it.

The entirety of the bracketted text "(including MEPs, MIPs and other
internal functions as appropriate)" should be deleted. It does not add to
"The intermediate nodes."

> The following text in the draft increases this suspicion:
>
> <quote>
>   Tandem Connection: A tandem connection is an arbitrary part of a
>   transport path that can be monitored (via OAM) independently from the
>   end-to-end monitoring (OAM).  It may be a monitored segment or a
>   monitored concatenated segment of a transport path.  The tandem
>   connection may also include the forwarding engine(s) of the node(s)
>   at the edge(s) of the segment or concatenated segment.
> <end quote>

Actually, I am quite fed up about this persistent insistence on the
inclusion of "Tandem Connection." The definition within the ITU-T of this
term is poorly specified and comes from the monitoring of a path that is
parallel (i.e. tandem) to the data path being monitored. This definition of
TC seems to be at variance, and would be if the ACH was actually in band.

> Doesn't "forwarding engine" sound like hardware to you?

Yes, but so what?

> IMHO it is worth noting that neither the MPLS-TP Requirements
> draft nor the MPLS-TP OAM requirements one
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01.txt)
> contain any requirements dealing with tandem connections.
>
> But tandem connections are discussed in the MPLS-TP OAM Framework draft
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt).

Right.
Let's just get rid of an unnecessary term and bring all the I-Ds into line.

> The bottom line, IMHO, is that some clarity regarding co-routed vs.
> associated
> bidirectional paths is still required. One way to provide that could be by
> explicitly
> limiting Requirement 34 to specific functionality.

Agreed.

Adrian

________________________________________
From: Adrian Farrel [[email-masked]]
Sent: Thursday, April 16, 2009 12:13 AM
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Sasha,

Not really sure whether you are misrepresenting anyone, but...

> 1. My reading of  one of Ben's  messages is that associated
> bidirectional paths are the only types of paths that can be
> created in the existing networks; "true" co-routed bidirectional
> paths will have to wait until (if ever) new equipment becomes
> available.

This is clearly nonsense!
>From the point of view of hardware, co-routed bidirectional LSPs are a
special case of associated bidirectional LSPs.

If you can set up two unidirectional LSPs (e.g. using the management plane)
you can surely set up a co-routed bidirectional LSP.

There are shipping solutions that achieve co-routed bidirectional LSPs using
the control plane. These either use the GMPLS (which is cleaner) or
non-standard proprietary solutions (which is messy but functional).

But (of course) the management plane or control plane solutions have nothing
to do with availability of equipment as they are software solutions.

> 2. My reading of one of Neil's messages is that the actual driver for
> co-routed
> bidirectional paths may be experience with existing transport networks
> rather
> than any specific benefit.

Isn't that the case with 75% of the MPLS-TP requirements?
Which is not to say it is a bad thing.

A large driver for MPLS-TP is to give the packet network the look, feel, and
behavioral characteristics of a "legacy" transport network.

> Based on these observations, I'd guess (FWIW) that:
> * associated bidirectional paths are, at least for the time
>    being, the most important type of bidirectional paths in
>    MPLS-TP

I think that is wrong both given my statement above, and given that other
upgrades to existing MPLS solutions will be needed to reach the full
function level of MPLS-TP.

> * they had a good chance to remain the only type of bidirectional
>   paths in  real deployments.

I don't see what that follows from.

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 16 Apr 2009 14:29:40 +0200

Sasha,
 
I do not agree with you nor Adrian in this matter as explained in my
response to Adrian's email a few minutes ago.
 
One of the applications that would not longer be able to function would be
1:1 PW SNC protection or 1:1 LSP SNC protection. For those protection
mechanisms we need TCM MEP functions to determine the status of each SNC.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: donderdag 16 april 2009 13:40
To: Adrian Farrel
Cc: [email-masked]; ITALO; [email-masked]
Subject: [mpls-tp] Co-routed bidirectional transport path requirement (was:
Associated bidirectional transport path requirements)

Adrian,

Looks as we are much more in agreement than it could be guessed from the
first round of exchanges.

I've changed the subject since we are actually discussing specifics of
co-routed bidirectional paths.

I fully support your proposal to get rid (in a consistent manner) from the
TC stuff in MPLS-TP, especially since, to the best of my knowledge,
operational experience with SONET/SDH TCM (ITU-T definitions
notwithstanding) did not prove its worth. If this is based on
mis-perception, I would be glad to hear that (especially from the operators
on this list).

And if it is possible to re-write Requirement 34 as a functional/behavior
requirement, it would be great, too.

Regards,

     Sasha

Hi Sasha,

OK. Got it.

Yes, but so what?

> draft nor the MPLS-TP OAM requirements one
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01.
txt)
> But tandem connections are discussed in the MPLS-TP OAM Framework draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt
).

Right.

Agreed.

Adrian

Hi Sasha,

Cheers,
Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Apr 2009 17:32:23 +0300

Maarten,
I've scanned the MPLS-TP Survivability Framework draft (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-00.txt) but did not find there any requirements for  1:1 SNC protection (indeed, the term SNC is not mentioned in this document).

And AFAIK 1:1 linear protection (which is mentioned in the draft) does not require any TCM functionality.

If the functionality you have in mind is called by any other name in the MPLS-TP Survivability Framework , it would be nice if you could provide an appropriate mapping. If not, let us not use it as a justification for additional OAM functionality like TCM.

Regards,
     Sasha

________________________________
From: Maarten Vissers [[email-masked]]
Sent: Thursday, April 16, 2009 3:29 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements)

Sasha,

I do not agree with you nor Adrian in this matter as explained in my response to Adrian's email a few minutes ago.

One of the applications that would not longer be able to function would be 1:1 PW SNC protection or 1:1 LSP SNC protection. For those protection mechanisms we need TCM MEP functions to determine the status of each SNC.

Regards,
Maarten

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: donderdag 16 april 2009 13:40
To: Adrian Farrel
Cc: [email-masked]; ITALO; [email-masked]
Subject: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements)

Adrian,

Regards,

     Sasha

Hi Sasha,

OK. Got it.

Yes, but so what?

Right.

Agreed.

Adrian

Hi Sasha,

Cheers,
Adrian

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Apr 2009 17:53:39 +0100

On 16/04/2009 12:39, "Alexander Vainshtein"
> I fully support your proposal to get rid (in a consistent manner) from the TC
> stuff in MPLS-TP, especially since, to the best of my knowledge, operational
> experience with SONET/SDH TCM (ITU-T definitions notwithstanding) did not
> prove its worth. If this is based on mis-perception, I would be glad to hear
> that (especially from the operators on this list).

BT has no requirement for TCM. We do not have it deployed in our TDM
networks today and have no current plans to use it in any of our networks in
the future.

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Apr 2009 19:25:02 +0200

Hi,
TC is a solution to the requirement to manage, monitor and protect the
network at different nested levels.
The work on MPLS-TP started with this basic requirement that came from
the ITU-T. 
I think we should continue and address this requirement as our
commitment to the ITU-T. 
About the solution, there is room for discussion. Is it TC, PST or
something else? As promised I'll provide next week some text about this.

Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Ben Niven-Jenkins
Sent: Thursday, April 16, 2009 7:54 PM
To: Alexander Vainshtein; Adrian Farrel
Cc: BUSI ITALO; [email-masked]
Subject: [mpls-tp] Requirement for TCM or not.

BT has no requirement for TCM. We do not have it deployed in our TDM
networks today and have no current plans to use it in any of our
networks in
the future.

Ben

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

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Apr 2009 10:54:39 -0700

Nurit,

As I recall, there is a 1:1 relationship between a TCM instance and the
LSP it is monitoring.  I thought we had agreed (a long time ago) to
generalize this into a 1:N capability, and hence TCM became PST.

Thanks,

John 

> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
> [mailto:[email-masked]] 
> Sent: Thursday, April 16, 2009 10:25 AM
> To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel
> Subject: Re: [mpls-tp] Requirement for TCM or not.
> 
> Hi,
> TC is a solution to the requirement to manage, monitor and 
> protect the network at different nested levels.
> The work on MPLS-TP started with this basic requirement that 
> came from the ITU-T. 
> I think we should continue and address this requirement as 
> our commitment to the ITU-T. 
> About the solution, there is room for discussion. Is it TC, 
> PST or something else? As promised I'll provide next week 
> some text about this.
> 
> Best regards,
> Nurit
> 
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Ben Niven-Jenkins
> > I fully support your proposal to get rid (in a consistent 
> manner) from
> the TC
> > experience with SONET/SDH TCM (ITU-T definitions 
> notwithstanding) did
> not
> BT has no requirement for TCM. We do not have it deployed in 
> our TDM networks today and have no current plans to use it in 
> any of our networks in the future.
> 
> Ben
>

---

From: <[email-masked]>
Date: Thu, 16 Apr 2009 19:29:25 +0100

Ben wrote  16 April 2009 17:54
> manner) from the TC
> notwithstanding) did not

I could not agree more with Ben on this.  I have, several times in the
past and on various IETF/ITU lists, attempted to explain why we in BT
hold this view.  But to very briefly recap:

-	the intrinsic reliability of the network technology/equipment we
expect our suppliers to provide us with should have a low intrinsic
defect probability....and in such cases an OAM philosophy that is
predicated on blanket configuration of multiple nested TCM levels is
totally at odds with the *rare* defect cases where one needs to look
*inside* an end-end *connection*.  {Aside=> Here I would prefer we
tap-off and end-end OAM flow on the *rare* occasions we need to.}  I
also highlight the word 'connection' here because the concept of TCM in
a cl-ps mode network is ridiculous IMO....but if it's that great then
please let us see it implemented in IPv4 and IPv6 first.....the fact
this has never been seen necessary here speaks volumes to me.

-	the 'always-on' defect detection/handling OAM *must* be orders
of magnitude more reliable than the *rare* defects we expect the network
to create.  So this 'always-on' type of OAM needs to be as sparse/simple
as is possible.  Configuration and processing of OAM also has a real
cost.  Moreover, having lots of configuration (read as 'TCM') is
completely the wrong direction to be going in wrt improving reliability
and reducing cost.

-	I have painstakingly explained in the past why network
technologies that are not top-of-stack have no needs for
UNIs/E-NNIs....let alone wasting ones time/money attempting
peer-interworking between technologies that are not even the same
network mode!  Those promoting this FUD should be ashamed of themselves
IMO as the technical justification is simply absent.  However, the key
point here is that nested TCM cannot be 'sold' on the basis of OAM being
ascribed to different party partitions of a single layer network.

-	the only points that remain invariant across failure/recovery
events are trail termination points (I am ignoring flow termination
points of cl-ps mode networks like IP because I see no reason for TCM
whatsoever here).  This means any nested TCM levels will need
reconfiguration across these events....unless one purposely creates
'pinch-points' and is thus is happy to compromise the potential
availability performance of a layer network just so one can see the TCM
working.

regards, Neil

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Apr 2009 22:42:10 +0300

Neil,
Lots of thanks for clarifying your (and BT) position and the rationale behind it.

I'd like to note that so far I haven't heard any major transport operator actively advocating 
usage of TCM in the existing (SONET/SDH) transport networks. Or did I miss something?

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]]
Sent: Thursday, April 16, 2009 9:29 PM
To: [email-masked]; Alexander Vainshtein; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] Requirement for TCM or not.

regards, Neil

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Apr 2009 22:49:01 +0300

Nurit hi,
Two comments:

1. As I see it, the actual operational need to monitor network at different nested levels is, at the very least,
    arguable (Neil explains this much better that I can ever can hope).

2. We should understand and agree upon the requirement first and then look for the suitable solution, not the
     the other way round. 

Regards,
     Sasha

________________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Thursday, April 16, 2009 8:25 PM
To: ext Ben Niven-Jenkins; Alexander Vainshtein; Adrian Farrel
Cc: BUSI ITALO; [email-masked]
Subject: RE: [mpls-tp] Requirement for TCM or not.

Hi,

Best regards,
Nurit

-----Original Message-----

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 16 Apr 2009 22:05:59 +0200

Sasha,
I absolutely agree with your second point.
Regarding the first one, it was agreed that the MPLS-TP addresses the
transport requirements of the ITU-T and additional requirements from
SPs. 
This was one of the first set of requirements the ITU-T brought to the
work and we need to address it.
Best regards,
Nurit

-----Original Message-----
From: ext Alexander Vainshtein [mailto:[email-masked]]

Sent: Thursday, April 16, 2009 10:49 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: BUSI ITALO; [email-masked]; ext Ben Niven-Jenkins; Adrian Farrel;
[email-masked]
Subject: RE: [mpls-tp] Requirement for TCM or not.

Nurit hi,
Two comments:

1. As I see it, the actual operational need to monitor network at
different nested levels is, at the very least,
    arguable (Neil explains this much better that I can ever can hope).

2. We should understand and agree upon the requirement first and then
look for the suitable solution, not the
     the other way round. 

Regards,
     Sasha

Hi,

Best regards,
Nurit

-----Original Message-----

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Apr 2009 21:20:18 +0100

Colleagues,

On 16/04/2009 21:05, "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
> work and we need to address it.

This does raise a question in my mind that goes back to something I have
said before. Is TCM a requirement because it is a real requirement that
operators are asking for or because we are recreating SDH/SONET
functionality blindly without considering its relevance in the world we now
live in?

I appreciate that there are many operators who do not participate in
standards, however it would be most useful if just one operator who requires
TCM were to step forward and say so.

I am not a TDM expert but what my TDM experts tell me is that TCM has been
deployed in the past by some operators (I have no idea of its current state
of deployment except in BT) but that its use in the past can be considered
(in their opinion) to be in the minority of deployments.

I do wonder if we are therefore expending a lot of energy (and later on time
both in standardisation and possibly development effort) for a function that
may be seldom, if ever, used. It won't be the first time we have
standardised something that is seldom, if ever, used but we do have an
opportunity now to take a step back and consider: is TCM really required and
if it is required, is it a priority in the development of MPLS-TP?

Ben

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 16 Apr 2009 16:41:04 -0400

If I am not mistaken, this is the third iteration of the
discussion cycle on this subject matter (each with
different heading). As they say, third time is a charm.

seriously though, I agree. Lets put this behind us if 
there is no 'real' requirement for it.

/himanshu

-----Original Message-----
From: [email-masked] on behalf of Ben Niven-Jenkins
Sent: Thu 4/16/2009 4:20 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] Requirement for TCM or not.
 
Colleagues,

Ben

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Apr 2009 13:46:35 -0700

+1 

> From: Shah, Himanshu [mailto:[email-masked]] 
> Sent: Thursday, April 16, 2009 1:41 PM
> To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod 
> HaSharon); ext Alexander Vainshtein
> discussion cycle on this subject matter (each with different 
> heading). As they say, third time is a charm.
> 
> seriously though, I agree. Lets put this behind us if there 
> is no 'real' requirement for it.
> 
> /himanshu
> 
> 
> 
> 
> 
> 
> 
> 
> This does raise a question in my mind that goes back to 
> something I have said before. Is TCM a requirement because it 
> is a real requirement that operators are asking for or 
> because we are recreating SDH/SONET functionality blindly 
> without considering its relevance in the world we now live in?
> 
> I appreciate that there are many operators who do not 
> participate in standards, however it would be most useful if 
> just one operator who requires TCM were to step forward and say so.
> 
> I am not a TDM expert but what my TDM experts tell me is that 
> TCM has been deployed in the past by some operators (I have 
> no idea of its current state of deployment except in BT) but 
> that its use in the past can be considered (in their opinion) 
> to be in the minority of deployments.
> 
> I do wonder if we are therefore expending a lot of energy 
> (and later on time both in standardisation and possibly 
> development effort) for a function that may be seldom, if 
> ever, used. It won't be the first time we have standardised 
> something that is seldom, if ever, used but we do have an 
> opportunity now to take a step back and consider: is TCM 
> really required and if it is required, is it a priority in 
> the development of MPLS-TP?
> 
> Ben
> 
>

---

From: [email-masked]
Date: Fri, 17 Apr 2009 11:03:39 +0800

sasha:
 i don't agree your advice, i think it is necessary to consider TCM 
functionality and protections in MPLS-TP survive framework.
it is complex and cost to apply end to end protection.
thank you.
liu

Alexander Vainshtein <[email-masked]> 
发件人:  [email-masked]
2009-04-16 22:32

收件人
Maarten Vissers <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: 
Associated bidirectional transport path requirements)

Maarten,
I've scanned the MPLS-TP Survivability Framework draft (
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-00.txt) 
but did not find there any requirements for  1:1 SNC protection (indeed, 
the term SNC is not mentioned in this document).
 
And AFAIK 1:1 linear protection (which is mentioned in the draft) does not 
require any TCM functionality.
 
If the functionality you have in mind is called by any other name in the 
MPLS-TP Survivability Framework , it would be nice if you could provide an 
appropriate mapping. If not, let us not use it as a justification for 
additional OAM functionality like TCM.
 
Regards,
     Sasha

 
From: Maarten Vissers [[email-masked]]
Sent: Thursday, April 16, 2009 3:29 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: RE: [mpls-tp] Co-routed bidirectional transport path requirement 
(was: Associated bidirectional transport path requirements)

Sasha,

 
Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Alexander Vainshtein
Sent: donderdag 16 april 2009 13:40
To: Adrian Farrel
Cc: [email-masked]; ITALO; [email-masked]
Subject: [mpls-tp] Co-routed bidirectional transport path requirement 
(was: Associated bidirectional transport path requirements)

Adrian,
 
mis-perception, I would be glad to hear that (especially from the 
operators on this list).

Regards,
     Sasha

Subject: Re: [mpls-tp] Associated bidirectional transport path 
requirements

Hi Sasha,

OK. Got it.

parallel (i.e. tandem) to the data path being monitored. This definition 
of

Yes, but so what?

> (
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01.txt
)
> (
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt
).

Right.
Let's just get rid of an unnecessary term and bring all the I-Ds into 
line.

Agreed.

Adrian

Subject: Re: [mpls-tp] Associated bidirectional transport path 
requirements

Hi Sasha,

If you can set up two unidirectional LSPs (e.g. using the management 
plane)
you can surely set up a co-routed bidirectional LSP.

There are shipping solutions that achieve co-routed bidirectional LSPs 
using
the control plane. These either use the GMPLS (which is cleaner) or
non-standard proprietary solutions (which is messy but functional).

But (of course) the management plane or control plane solutions have 
nothing
to do with availability of equipment as they are software solutions.

A large driver for MPLS-TP is to give the packet network the look, feel, 
and
behavioral characteristics of a "legacy" transport network.

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 17 Apr 2009 10:49:35 +0300

Liu,
Thank you for a prompt response.

To make it clear, I did not advocate 1:1 linear (a.k.a. end-to-end) protection for MPLS-TP. I've only mentioned it as the only 1:1 protection scheme I've found in the MPLS-TP Survivability Framework draft.

To take one step further, IMHO and FWIW, specific protection schemes and monitoring mechanisms are not tightly coupled, and preferably should remain so. Hence any attempt to justify existence of a certain monitoring mechanism (and TCM clearly falls in the this category - it stands for Tandem Connection Monitoring) by reference to a certain protection scheme would look faulty to me. And if, on top of this, the protection scheme in question is not even mentioned n the Survivability Framework draft... no need to continue, I think.

(Of course this does not mean that additional protection schemes cannot appear in the MPLS-TP Survivability Framework draft. On the other hand, some of the schemes now in the draft may be eventually dropped or, at least, downgraded from MUST to SHOULD or MAY. But this is a different topic).

Last but not least, we are currently discussing MPLS-TP requirements, and these requirements presumably should be based on experience of the transport operators. As some people (including myself) have noted, in the two rounds of earlier discussions no transport operators have not explicitly required TCM.  In this (3rd!) round at least one major operator has explicitly stated that TCM is not needed.

Regards,
     Sasha

________________________________
From: [email-masked] [[email-masked]]
Sent: Friday, April 17, 2009 6:03 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements)

sasha:
 i don't agree your advice, i think it is necessary to consider TCM functionality and protections in MPLS-TP survive framework.
it is complex and cost to apply end to end protection.
thank you.
liu

2009-04-16 22:32

收件人
        Maarten Vissers <[email-masked]>
抄送
        "[email-masked]" <[email-masked]>
主题
        Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements)

Maarten,

Regards,
     Sasha

Sasha,

Regards,
Maarten

Adrian,

Regards,
     Sasha

Hi Sasha,

OK. Got it.

Yes, but so what?

Right.

Agreed.

Adrian

Hi Sasha,

Cheers,

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 17 Apr 2009 10:20:09 +0200

John,

There is a 1:1 relationship between a TCM instance and the LSP it is
monitoring. I have never agreed to generalize it into a 1:N
relationship.

Italo

> From: Drake, John E [mailto:[email-masked]] 
> Sent: Thursday, April 16, 2009 7:55 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Ben 
> Niven-Jenkins; Alexander Vainshtein; Adrian Farrel
> > > prove its worth. If this is based on mis-perception, I 
> would be glad
> > to hear

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 17 Apr 2009 10:22:39 +0200

I am in full agreement with Nurit

Italo 

> Sent: Thursday, April 16, 2009 10:06 PM
> To: ext Alexander Vainshtein
> Cc: BUSI ITALO; [email-masked]; ext Ben Niven-Jenkins; 
> Adrian Farrel; [email-masked]
> From: ext Alexander Vainshtein 
> [mailto:[email-masked]]
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 17 Apr 2009 10:43:49 +0200

Hi all,

I am sorry to repeat myself, but it seems that we are all repeating the
debate we already had in the past.

It is therefore important that I remind everybody that the requirement
for TCM is not motivate by its existence in SONET/SDH.

Actually, the TCM function was added to SONET/SDH quite late in its
development on the basis of transport operators requirements.

Because of its late introduction, the SONET/SDH TCM design has some
limitations (e.g. the lack of nesting TCM) that has limited its
applicability. This is the main reason why TCM was not widespread
deployed with SONET/SDH, although some deployments actually exist.

I think that we are continuing to ignore that SONET/SDH is not the only
transport technology defined by ITU-T.

After having realized the issues with SONET/SDH TCM design, all the
subsequent OAM designs from ITU-T has taken seriously into account the
TCM requirements, including the nesting: look for example at OTN and
Ethernet OAM designs.

Italo

> From: Ben Niven-Jenkins [mailto:[email-masked]] 
> Sent: Thursday, April 16, 2009 10:20 PM
> Cc: BUSI ITALO; [email-masked]; Adrian Farrel; 
> [email-masked]
> something I have
> TCM has been
> (and later on time
> really required and

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Fri, 17 Apr 2009 10:51:59 +0200

Hi Sasha , 
I agree with Maarten and Liu.
 
Co-routed bidirectional path  as well as TCM functionality are basic requirement in transport network  
If we think that these requirements are not clearly specified in mpls-tp documents than we must better address them .

Regards
Annamaria 

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: venerdì 17 aprile 2009 5.04
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement (was: Associated bidirectional transport path requirements)

sasha: 

2009-04-16 22:32 

收件人

Maarten, 
I've scanned the MPLS-TP Survivability Framework draft (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-00.txt <http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-00.txt> ) but did not find there any requirements for  1:1 SNC protection (indeed, the term SNC is not mentioned in this document). 

  
Regards, 
     Sasha 

  

Sasha, 

  
Regards, 
Maarten 

Adrian, 

  
Regards, 
     Sasha 

Hi Sasha,

OK. Got it.

Yes, but so what?

Right.

Agreed.

Adrian

Hi Sasha,

Cheers,

---

From: [email-masked]
Date: Fri, 17 Apr 2009 16:58:02 +0800

sasha:
 thank you for your detail explain, you may be true for your 
understanding. here I can't advocate there must be TCM conception and 
funcation in MPLS-TP requirement,  but mpls-tp should have the 
requirements of sub-layer or segement protections like SNCP in SDH/SONET 
network. maybe the requirements not be applyed for some service 
prividers,but it may privide them with  more choices for service 
prividers.

regards
liu

2009-04-17 15:49

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
RE: [mpls-tp] Co-routed bidirectional transport path requirement (was: 
Associated bidirectional transport path requirements)

Liu,
 
To make it clear, I did not advocate 1:1 linear (a.k.a. end-to-end) 
protection for MPLS-TP. I've only mentioned it as the only 1:1 protection 
scheme I've found in the MPLS-TP Survivability Framework draft.
 
To take one step further, IMHO and FWIW, specific protection schemes and 
monitoring mechanisms are not tightly coupled, and preferably should 
remain so. Hence any attempt to justify existence of a certain monitoring 
mechanism (and TCM clearly falls in the this category - it stands for 
Tandem Connection Monitoring) by reference to a certain protection scheme 
would look faulty to me. And if, on top of this, the protection scheme in 
question is not even mentioned n the Survivability Framework draft... no 
need to continue, I think.
 
(Of course this does not mean that additional protection schemes cannot 
appear in the MPLS-TP Survivability Framework draft. On the other hand, 
some of the schemes now in the draft may be eventually dropped or, at 
least, downgraded from MUST to SHOULD or MAY. But this is a different 
topic).
 
Last but not least, we are currently discussing MPLS-TP requirements, and 
these requirements presumably should be based on experience of the 
transport operators. As some people (including myself) have noted, in the 
two rounds of earlier discussions no transport operators have not 
explicitly required TCM.  In this (3rd!) round at least one major operator 
has explicitly stated that TCM is not needed. 
 
Regards,
     Sasha

From: [email-masked] [[email-masked]]
Sent: Friday, April 17, 2009 6:03 AM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Co-routed bidirectional transport path requirement 
(was: Associated bidirectional transport path requirements)

sasha: 

收件人

Maarten, 

  
Regards, 
     Sasha 

 

Sasha, 

  
Regards, 
Maarten 

Adrian, 

  
Regards, 
     Sasha 

Hi Sasha,

OK. Got it.

Yes, but so what?

Right.

Agreed.

Adrian

Hi Sasha,

Cheers,

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 17 Apr 2009 11:13:59 +0200

Sasha,
 
the survivability framework should be a document that describes a
framework for the solutions that meet MPLS-TP survivability
requirements.
 
MPLS-TP Survivability Requirements are defined in section 2.8 of
draft-ietf-mpls-tp-requirements-06.
 
In particular Req.56 requirese the capability of MPLS-TP to protect a
segment or a concatenated segment of a transport path:
 
   56  MPLS-TP recovery mechanisms MUST be applicable at various levels
       throughout the network including support for link, transport
       path, segment, concatenated segment and end to end recovery.

My understanding is that SNCP means protecting a segment or concatenated
segment of a transport path.
 
If my understanding is correct we can catch this translation in the next
update of the Rosetta stone draft.
 
Italo

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexander Vainshtein
	Sent: Thursday, April 16, 2009 4:32 PM
	To: Maarten Vissers
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Co-routed bidirectional transport path
requirement (was: Associated bidirectional transport path requirements)

	Maarten,
	I've scanned the MPLS-TP Survivability Framework draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-00.t
xt) but did not find there any requirements for  1:1 SNC protection
(indeed, the term SNC is not mentioned in this document).
	 
	And AFAIK 1:1 linear protection (which is mentioned in the
draft) does not require any TCM functionality.
	 
	If the functionality you have in mind is called by any other
name in the MPLS-TP Survivability Framework , it would be nice if you
could provide an appropriate mapping. If not, let us not use it as a
justification for additional OAM functionality like TCM.
	 
	Regards,
	     Sasha

	 

	From: Maarten Vissers [[email-masked]]
	Sent: Thursday, April 16, 2009 3:29 PM
	To: Alexander Vainshtein
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Co-routed bidirectional transport path
requirement (was: Associated bidirectional transport path requirements)

	Sasha,
	 
	I do not agree with you nor Adrian in this matter as explained
in my response to Adrian's email a few minutes ago.
	 
	One of the applications that would not longer be able to
function would be 1:1 PW SNC protection or 1:1 LSP SNC protection. For
those protection mechanisms we need TCM MEP functions to determine the
status of each SNC.
	 
	Regards,
	Maarten

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexander Vainshtein
	Sent: donderdag 16 april 2009 13:40
	To: Adrian Farrel
	Cc: [email-masked]; ITALO; [email-masked]
	Subject: [mpls-tp] Co-routed bidirectional transport path
requirement (was: Associated bidirectional transport path requirements)

	Adrian,

	Looks as we are much more in agreement than it could be guessed
from the first round of exchanges.

	I've changed the subject since we are actually discussing
specifics of co-routed bidirectional paths.

	I fully support your proposal to get rid (in a consistent
manner) from the TC stuff in MPLS-TP, especially since, to the best of
my knowledge, operational experience with SONET/SDH TCM (ITU-T
definitions notwithstanding) did not prove its worth. If this is based
on mis-perception, I would be glad to hear that (especially from the
operators on this list).

	And if it is possible to re-write Requirement 34 as a
functional/behavior requirement, it would be great, too.

	However, I am not sure this would be easy (Ben, my apologies
again).

	Regards,

	     Sasha

	
	
	Hi Sasha,

	OK. Got it.

	
	>       relationship of the forward and the backward directions
of that
	
	There is no way this is a functional requirement. That is, there
is
	*nothing* that can be observed from a black box point of view
that results
	from adhering to this requirement.
	
	Therefore it could be assumed that this requirement is met by
configuring
	some data plane database component through the management plane.
The
	database component is not used for anything except to satisfy
this
	requirement for "awareness".
	
	Ben! Can we please try to rewrite this requirement in terms of
behavior?
	
	> may be required in order to comply with it.
	
	The entirety of the bracketted text "(including MEPs, MIPs and
other
	internal functions as appropriate)" should be deleted. It does
not add to
	"The intermediate nodes."
	
	>   at the edge(s) of the segment or concatenated segment.
	
	Actually, I am quite fed up about this persistent insistence on
the
	inclusion of "Tandem Connection." The definition within the
ITU-T of this
	term is poorly specified and comes from the monitoring of a path
that is
	parallel (i.e. tandem) to the data path being monitored. This
definition of
	TC seems to be at variance, and would be if the ACH was actually
in band.

	Yes, but so what?
	
	> draft nor the MPLS-TP OAM requirements one
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements
-01.txt)
	> But tandem connections are discussed in the MPLS-TP OAM
Framework draft
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00
.txt).
	
	Right.
	Let's just get rid of an unnecessary term and bring all the I-Ds
into line.

	Agreed.
	
	Adrian

	
	
	Hi Sasha,

	
are a
	
	If you can set up two unidirectional LSPs (e.g. using the
management plane)
	you can surely set up a co-routed bidirectional LSP.
	
	There are shipping solutions that achieve co-routed
bidirectional LSPs using
	the control plane. These either use the GMPLS (which is cleaner)
or
	non-standard proprietary solutions (which is messy but
functional).
	
	But (of course) the management plane or control plane solutions
have nothing
	to do with availability of equipment as they are software
solutions.

	
	A large driver for MPLS-TP is to give the packet network the
look, feel, and
	behavioral characteristics of a "legacy" transport network.
	
	>    being, the most important type of bidirectional paths in
	
	I think that is wrong both given my statement above, and given
that other
	upgrades to existing MPLS solutions will be needed to reach the
full
	function level of MPLS-TP.

	
	Cheers,
	Adrian

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 10:15:57 +0100

Italo,
 
wrote 17 April 2009 09:44
> TCM requirements, including the nesting: look for example at OTN and

NH=> Yes but how much of this is used in reality Italo?  TCM as a
concept has been around for a very long time and I don't know anyone
here who laments us not using it....though I know a large number of
folks who think it is not a great idea.  Remember what I have said in
previous mails, eg
-	the always-on defect detection/handling OAM needs to be as
simple/sparse as possible with min config and it must be significantly
more reliable then the network it is monitoring....
-	....and the intrinsic defect rate of the network must be very
low else it is not fit-for-purpose anyway...
-	.....so an OAM phiolosophy of blanketing the network with lots
of nested TCM level configuration is clearly the wrong way to be going.
-	And this is especially true when we are dealing with a non
top-of-stack network that has no technical need to peer and have E-NNIs
across several different parties. 

Since you mention Ethernet (which is cl-ps in native form) perhaps we
should have a clear understanding of how TCM will be applied to IPv4 and
IPv6.  I do not think it sensible that TCM should be considered in
isolation wrt MPLS-TP within IETF and for it not to be applied to
IP....if it's that important I would want to see clear work-plan
intentions for it to apply to all co-cs, co-ps and cl-ps technologies
that IETF have an interest in.

And as a follow-on from that, I would want to understand how this
factors into the work of CCAMPs wrt GMPLS.....the issue here of course
is a desire to understand how nested TCM levels are configured wrt
activation/deactivation across changes in routing when there is a
failure/recovery event.

regards, Neil

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Fri, 17 Apr 2009 11:25:17 +0200

Honestly, I do not see the real reason for so long discussion aroun
this. We all know that it was agreed by the JWT to use existing
constructs to provide this functionaliy (LSP hierarchy). 
So why should one care to include this requreiment that came from the
first point from the ITU-T?

From: ext Shah, Himanshu [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 11:41 PM
To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod HaSharon); ext
Alexander Vainshtein
Cc: BUSI ITALO; [email-masked]
Subject: RE: [mpls-tp] Requirement for TCM or not.

/himanshu

-----Original Message-----

Colleagues,

This does raise a question in my mind that goes back to something I have
said before. Is TCM a requirement because it is a real requirement that
operators are asking for or because we are recreating SDH/SONET
functionality blindly without considering its relevance in the world we
now
live in?

I appreciate that there are many operators who do not participate in
standards, however it would be most useful if just one operator who
requires
TCM were to step forward and say so.

I am not a TDM expert but what my TDM experts tell me is that TCM has
been
deployed in the past by some operators (I have no idea of its current
state
of deployment except in BT) but that its use in the past can be
considered
(in their opinion) to be in the minority of deployments.

I do wonder if we are therefore expending a lot of energy (and later on
time
both in standardisation and possibly development effort) for a function
that
may be seldom, if ever, used. It won't be the first time we have
standardised something that is seldom, if ever, used but we do have an
opportunity now to take a step back and consider: is TCM really required
and
if it is required, is it a priority in the development of MPLS-TP?

Ben

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 10:52:45 +0100

We care about it Nurit because it represents an operational cost and
source of potentially worse reliability.  I can tell you for a fact that
OPs folks will turn-off as much unnecessary OAM as they can.  I care
about it as a thinking engineer because I can see better ways to do
**rare** within-connection diagnostics.  Which is also why I care about
not creating unnecessary work/costs wrt trying to peer interwork non
top-of-stack networks because I and my colleagues can figure out that it
is a technical nonsence...and TCM must never be justified on that basis.

Further, we do not want to use suppliers whose equipment has such a high
intrinsic defect rate that having shed-loads of OAM running is
required....wrong approach.
 
But let me end with what I said in a different mail...if TCM is
considered essential for MPLS-TP, then I want to see IETF agree to its
adoptionfor IP.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
	Sent: 17 April 2009 10:25
	To: ext Shah, Himanshu; Niven-jenkins,B,Ben,DMF R; ext Alexander
Vainshtein
	Cc: BUSI ITALO; [email-masked]
	Subject: Re: [mpls-tp] Requirement for TCM or not.

	Honestly, I do not see the real reason for so long discussion
aroun this. We all know that it was agreed by the JWT to use existing
constructs to provide this functionaliy (LSP hierarchy). 
	So why should one care to include this requreiment that came
from the first point from the ITU-T?

	To: Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod HaSharon);
ext Alexander Vainshtein

	
	/himanshu

	 

	-----Original Message-----

	To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander
Vainshtein
	
	Colleagues,

	This does raise a question in my mind that goes back to
something I have
	said before. Is TCM a requirement because it is a real
requirement that
	operators are asking for or because we are recreating SDH/SONET
	functionality blindly without considering its relevance in the
world we now
	live in?
	
	I appreciate that there are many operators who do not
participate in
	standards, however it would be most useful if just one operator
who requires
	TCM were to step forward and say so.
	
	I am not a TDM expert but what my TDM experts tell me is that
TCM has been
	deployed in the past by some operators (I have no idea of its
current state
	of deployment except in BT) but that its use in the past can be
considered
	(in their opinion) to be in the minority of deployments.
	
	I do wonder if we are therefore expending a lot of energy (and
later on time
	both in standardisation and possibly development effort) for a
function that
	may be seldom, if ever, used. It won't be the first time we have
	standardised something that is seldom, if ever, used but we do
have an
	opportunity now to take a step back and consider: is TCM really
required and
	if it is required, is it a priority in the development of
MPLS-TP?
	
	Ben

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Fri, 17 Apr 2009 10:56:53 +0200

+1
Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI ITALO
Sent: venerdì 17 aprile 2009 10.23
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Requirement for TCM or not.

Italo 

> Cc: BUSI ITALO; [email-masked]; ext Ben Niven-Jenkins; Adrian 
> Farrel; [email-masked]
> Cc: BUSI ITALO; [email-masked]; ext Ben Niven-Jenkins; Adrian 
> Farrel; [email-masked]
> networks in the future.

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Apr 2009 11:21:55 +0100

Italo,

We sat in a small room in Geneva and discussed this extensively.

The requirement you expressed there was to be able to diagnose individual 
paths. It was not a requirement to perform any specific solution.

If we are going to make any progress at all we must learn to decouple 
requirements from solutions. We are engineers, so this is hard - as soon as 
we see a problem we think of a solution. But to get the solution right we 
must work out how to express our requirements clearly as functional behavior 
in terms of basic building blocks.

Adrian
----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: "Drake, John E" <[email-masked]>; "Sprecher, Nurit (NSN - 
IL/Hod HaSharon)" <[email-masked]>; "ext Ben Niven-Jenkins" 
<[email-masked]>; "Alexander Vainshtein" 
<[email-masked]>; "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 17, 2009 9:20 AM
Subject: RE: [mpls-tp] Requirement for TCM or not.

John,

Italo

---

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Sat, 18 Apr 2009 14:10:16 +0800

+1.
Could we use nested LSP to replace TCM?

Sincerely Yours
Xueqin Wei (Shuetsing Wei)

2009-04-18  14:08:14

==================== Following is your email=====================
Subject:Re: [mpls-tp] Requirement for TCM or not.
Sent：2009-04-17 04:36:57
From:Shah, Himanshu
To:Ben Niven-Jenkins; Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Alexander Vainshtein
CC to:BUSI ITALO; mpls-tp

>if it is required, is it a priority in the development of MPLS-TP?

=================================================================