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

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 11 Apr 2009 22:12:55 +0100

Maarten,

Apologies I didn't respond to this sooner.

On 30/03/2009 06:11, "Maarten Vissers" <[email-masked]> wrote:
>> I do not want to build an MPLS-TP network.
>> I want to use some MPLS-TP functionality in my existing deployed
> boxes/implementations.
> 
> This is an interesting new application. Please provide some further detail
> so that it is possible to judge if this adds requirements beyond the scope
> of MPLS-TP on the tools under development of MPLS-TP.

I am not sure what detail you are seeking.

The use case is relatively simple. I have a deployed MPLS network (several
actually) and I need some additional features such as static provisioning
and performance monitoring for particular deployment scenarios. It appears
that these functions that I require are being addressed as part of MPLS-TP.

So I have a choice:
1) Ensure those MPLS-TP mechanisms that I require are built in such a way
that they can also be applied to my existing MPLS networks.
2) Define a separate set of functionally identical mechanisms for MPLS.

I favour (1).

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 13 Apr 2009 09:36:13 +0200

Ben,

The detail I am seeking is to understand where your MPLS networks differ
from the MPLS-TP network definitions. E.g. 
- what are the transport path constructs (MP2P LSPs?), 
- what is/are the transport service layer technology (EVC?) or technologies
(MS-PW+EVC?).

Especially when the transport path construct in your MPLS netowrk is not the
P2P construct it is important to document what else it is, as the MPLS-TP
OAM at this point in time must support P2P and P2MP LSPs, but is not
required to support MP2P LSPs. As I have indicated in a previous email, a
MP2P LSP can be supported by MPLS-TP OAM that is reusing the Y.1731 OAM PDUs
and processing as Y.1731 OAM PDUs are designed to operate in transport paths
with multiple input ports.

A full "mesh" of MP2P transport paths/LSPs (i.e. N MP2P LSPs interconnecting
N PE nodes) can be equipped with Y.1731 based MPLS-TP OAM to check
connectivity of the NxN P2P Maintenance Entities that are supported by those
N MP2P LSPs. 
This OAM supports Loss of Connectivity, Loss of Continuity/MisMerge, Alarm
Suppression, Remote Defect Indication. Delay Measurement, Delay Variation
Measurement and Loopback mechanisms. 
The only mechanism not supported on such MP2P LSPs is Packet Loss
Measurement between the LSP Network Connection endpoints located in the PE
nodes. Packet/Frame Loss Measurement is still supported in the transport
service layer for each of the services. And it is possible to support Packet
Loss Measurement in the MP2P LSP on a per LSP link connection basis (LSP
link connections are P2P constructs); i.e. using P2P LSP Link Connection
Monitoring.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: zaterdag 11 april 2009 23:13
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Maarten,

On 30/03/2009 06:11, "Maarten Vissers" <[email-masked]> wrote:
> This is an interesting new application. Please provide some further 
> detail so that it is possible to judge if this adds requirements 
> beyond the scope of MPLS-TP on the tools under development of MPLS-TP.

So I have a choice:

I favour (1).

Ben

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 14 Apr 2009 12:12:10 +0200

I agree with Ben that any mechanisms defined for MPLS-TP can be applied,
as much as possible, also to existing MPLS networks.

I think that the GAL/G-ACh draft is a good example of how to achieve
this objective. GAL/G-ACh have been invented for MPLS-TP but defined to
be applicable to MPLS in general and in such a way that future features
can be also defined for applications other than MPLS-TP.

However, it could well be the case that it is not possible to support
some requirements with some existing MPLS constucts (e.g. mp2p LSP). In
this case, I think we still need define the mechanisms to address these
requirements and limit their usage to only p2p and p2mp LSPs.

I think there is some confusion regarding two aspects of the work we are
doing.

In my understanding we are working on two different targets in parallel:

A) extending MPLS protocol such that a profile for its usage in
transport network can be defined

B) defining a transport profile of MPLS (i.e. MPLS-TP)

I have somewhat the perception that in many discussions people are
mixing the different objectives.

For example, regarding this discussion, I think that:

1) it is very reasonable to require associated bidirectional paths in
the scope of MPLS in general (i.e. point A) such that we will define new
mechanisms such that they can work also with associated bidirectional
paths (if possible)

2) we need to be clear that asssociated bidirectional paths are not
required in transport networks (e.g. MPLS-TP)

Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Monday, April 13, 2009 9:36 AM
> To: 'Ben Niven-Jenkins'
> Cc: [email-masked]
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 15 Apr 2009 10:27:20 -0400

Italo,

> required in transport networks (e.g. MPLS-TP)

This doesn't match draft-ietf-mpls-tp-requirements-06.  Are you 
proposing dropping associated bidirectional path from the TP 
requirements document?

Lou

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 15 Apr 2009 18:34:07 +0300

Italo, Lou and all,

I apologize if I have misinterpreted some of the messages on this list, 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. 

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.

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
* they had a good chance to remain the only type of bidirectional paths in  real deployments.

My 2c,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lou Berger [[email-masked]]
Sent: Wednesday, April 15, 2009 5:27 PM
To: BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Italo,

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Apr 2009 22:13:00 +0100

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.

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

>   paths in  real deployments.

I don't see what that follows from.

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 16 Apr 2009 07:27:33 +0200

Adrian,

I agree with your observation. E.g. Packet Transport Network (PTN) products
deploy co-routed bidirectional LSPs.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: woensdag 15 april 2009 23:13
To: Alexander Vainshtein; Lou Berger; BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Sasha,

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

> co-routed bidirectional paths may be experience with existing 
> transport networks rather than any specific benefit.

Cheers,
Adrian

---

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

Adrian,
Thank you for a prompt and detailed response.

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
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.txt):

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

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

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

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. 

My 2c,
     Sasha

________________________________________
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,

Cheers,
Adrian

---

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

Colleagues,

A general comment from me.

We talk about transport networks as a single entity as that makes discussion
easier, but reality is that they are not all the same, if they were then
operators would have no need to employ architects like myself, they would
just purchase a life sized Airfix[1] network kit and build a transport
network using it.

Like all standards work it is about compromise.
Ben

[1] http://en.wikipedia.org/wiki/Airfix

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Apr 2009 10:58:22 +0100

Colleagues,

I can't help but feel we are overanalysing things here. How many
technologies/protocols/mechanisms have we successfully defined in both IETF
& ITU-T without this level of analysis of the initial requirements - a great
many (a good chunk of which were extremely successful).

The requirements document is not about specifying solutions.

The key question is: are the requirements clear enough that it is understood
what is required so someone could build a box/protocol/whatever to meet
them?

If we want to go into the nth level of detail on each requirement we will
still be debating this by the time I retire (which isn't due until 2045).

Ben

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Apr 2009 13:02:04 +0300

Adrian,

My previous response to your message has been too long already while dealing only with one item in this message.

I'd like to add that I fully agree with what I perceive as the other key statement in your message:

<quote>

     ("That" standing for "Experience with existing transport networks rather than any specific benefit")
     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
<end quote>

The only question here is, to what extent this experience and  these behavioral characteristics (which, to the best of my understanding, mainly have dealt with P2P co-routed bidirectional paths with symmetric BW allocation) can advance the proclaimed MPLS-TP goals, which include:

 *   Unidirectional P2MP paths
 *   Bidirectional paths with asymmetric BW allocation
 *   Associated (not co-routed) bidirectional paths.

E.g., I suspect that the need for associated bidirectional paths may be closely related to the need to support bidirectional paths with asymmetric BW allocation...

My 2c,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Alexander Vainshtein [[email-masked]]
Sent: Thursday, April 16, 2009 10:04 AM
To: Adrian Farrel
Cc: [email-masked]; ITALO; [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Adrian,

<quote>

<quote>

<quote>

My 2c,
     Sasha

Hi Sasha,

Cheers,
Adrian

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Apr 2009 11:07:58 +0100

Sasha,

On 15/04/2009 16:34, "Alexander Vainshtein"
<[email-masked]> wrote:

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

Not really IMO. If we have the starting base of a standardised MPLS
implementation then IMO (but I don't build equipment) associated
bi-directional "only" requires changes to an individual boxes implementation
and how it internally models/represents various network elements (e.g.
LSPs).

Co-routed bi-directional paths require new protocol mechanisms (be it
reusing GMPLS or creating something new). Changing the protocols used in a
deployed network is not easy, it is painful both in terms of effecting any
migration, changing systems, upgrading equipment, reskilling operations,
etc. It is not a task undertaken lightly. Changing behaviour of a single box
is much easier (but not always child's play).

I think there are benefits to co-routed bidirectional paths but there is
also pain to getting them into existing deployed networks. Associated
bi-directional provides a means to achieve some of the benefits with less of
the pain IMO.

I would further add that from a customer of the transport network's
perspective due to the client/server relationship and independence whether
the underlying transport network uses associated bidirectional or co-routed
bidirectional is transparent to the customer provided the transport network
provides the necessary performance that the customer requires.

I would also note that PWs running over a standardised MPLS network today
are associated bi-directional entities and they are being used successfully
today to support at least some transport network services such as Circuit
Emulation.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Apr 2009 10:59:23 +0100

Hi Sasha,

> 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?

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

> 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

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

Hi Sasha,

Cheers,
Adrian

---

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

Adrian,

> *nothing* that can be observed from a black box point of view that
> results from adhering to this requirement.

Your understanding is not correct. It is very much observable if this
requirement is met from a black box point of view. The MIP functions can
only perform the Loopback when there is a co-routed bidirectional transport
path. The MPLS-TP LBM packet received at a MIP needs to be returned (as LBR
packet) to the originating MEP function via the other direction of the
co-routed bidirectional transport path. This other direction would not be
available in an associated bidirectional transport path... and thus the
loopback test would fail.

Similarly, when we have to apply TCM MEPs to monitor a segment, then this is
possible in a co-routed bidir transport path but not in a associated bidir
transport path. In the first case the TCM MEP Source and Sink functions are
co-located and can exchange what is called "remote information" which is
necessary for performance monitoring. In the latter case the TCM MEP Source
and Sink functions are in e.g. different nodes in the network and TCM would
not be able to provide performance monitoring.

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

Your understanding is not correct. This text must not be deleted at all.

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

I don't understand where your interpretation of tandem connection is
described in ITU-T recommendations. I.e. "from the monitoring of a path that
is parallel (i.e. tandem) to the data path being monitored."?

There is a "network connection" and this network connection is a set of
interconnected "link connections" and "matrix connections". A subset of
those interconnected link connections and matrix connections can be
monitored and is then referred to as a "tandem connection". There is no
"path that is parallel to the data path". There is only additional OAM
inserted inside the data path by the TCM MEP_So function and this OAM is
extracted from the data path by the TCM MEP_Sk function. 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: donderdag 16 april 2009 11:59
To: Alexander Vainshtein; [email-masked]
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Hi Sasha,

> This statement would be obviously correct, were it not for Requirement 
> 34 in the latest MPLS-TP requirements draft

OK. Got it.

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

Yes, but so what?

> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen
> ts-01.txt) contain any requirements dealing with tandem connections.
>
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-00.txt
).

Right.

> bidirectional paths is still required. One way to provide that could 
> be by explicitly limiting Requirement 34 to specific functionality.

Agreed.

Adrian

Hi Sasha,

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Apr 2009 13:48:27 +0100

Maarten,

You take the requirement that is stated in the document and make a claim 
based on some *other* function that you want to achieve.

In order to write a good requirements document, you must learn to state the 
functional requirement and not the solutions that you assume (perhaps 
correctly) are necessary to meet the requirement.

So, from your example, you have a requirement to be able to perform loopback 
OAM at MIPs. Why not state that requirement and allow the solutions to flow 
from that?

As to the following...

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

I can only thank you for your constructive and well-reasoned argument.

The original text reads...

       path

Since MEPs, MIPs and other internal functions are just examples of 
intermediate nodes, the sentence loses nothing if it reads

       The intermediate nodes of a co-routed bidirectional transport
       path

Furthermore, *any* text that reaches me as AD including "as appropriate" is 
highly likely to be turned around. If the authors do not know what they mean 
and have used the phrase to avoid working it out, then it needs to be fixed. 
If the authors do know what they mean, they should say it.

Wrt "Tandem Connection" I'm not sure it is a fruitful discussion. Have a 
look at TDM OAM and tell me whether the OAM is actually inserted in the data 
path (hint: why is it called "overhead"?). None of this discussion of TCM is 
useful. The term is redundant. Adding redundant terms does not increase 
clarity.

Adrian

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 16 Apr 2009 06:02:57 -0700

+1 

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Thursday, April 16, 2009 5:48 AM
> To: Maarten Vissers
> Cc: [email-masked]
> Subject: [mpls-tp] Requirement 34 and TCM[Was: Associated 
> bidirectionaltransport path requirements]
> 
> Maarten,
> 
> You take the requirement that is stated in the document and 
> make a claim based on some *other* function that you want to achieve.
> 
> In order to write a good requirements document, you must 
> learn to state the functional requirement and not the 
> solutions that you assume (perhaps
> So, from your example, you have a requirement to be able to 
> perform loopback OAM at MIPs. Why not state that requirement 
> and allow the solutions to flow from that?
> 
> 
> As to the following...
> 
> >> internal functions as appropriate)" should be deleted. It does not 
> >> add to "The intermediate nodes."
> >
> Since MEPs, MIPs and other internal functions are just 
> examples of intermediate nodes, the sentence loses nothing if it reads
> 
> Furthermore, *any* text that reaches me as AD including "as 
> appropriate" is highly likely to be turned around. If the 
> authors do not know what they mean and have used the phrase 
> to avoid working it out, then it needs to be fixed. 
> Wrt "Tandem Connection" I'm not sure it is a fruitful 
> discussion. Have a look at TDM OAM and tell me whether the 
> OAM is actually inserted in the data path (hint: why is it 
> called "overhead"?). None of this discussion of TCM is 
> useful. The term is redundant. Adding redundant terms does 
> not increase clarity.
> 
> Adrian
> 
> 
> > path. The MPLS-TP LBM packet received at a MIP needs to be 
> returned (as 
> > LBR
> > Similarly, when we have to apply TCM MEPs to monitor a 
> segment, then this 
> > is
> > transport path. In the first case the TCM MEP Source and 
> Sink functions 
> > are
> > necessary for performance monitoring. In the latter case 
> the TCM MEP 
> > Source
> > and Sink functions are in e.g. different nodes in the 
> network and TCM 
> > would
> > described in ITU-T recommendations. I.e. "from the 
> monitoring of a path 
> > that
> [mailto:[email-masked]] On Behalf
> > Of Adrian Farrel
> > parallel (i.e. tandem) to the data path being monitored. 
> This definition 
> > of
> > Let's just get rid of an unnecessary term and bring all the 
> I-Ds into 
> > line.
> >
> > If you can set up two unidirectional LSPs (e.g. using the 
> management 
> > plane)
> > There are shipping solutions that achieve co-routed 
> bidirectional LSPs 
> > using
> > But (of course) the management plane or control plane 
> solutions have 
> > nothing
> > A large driver for MPLS-TP is to give the packet network 
> the look, feel, 
> > and

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Apr 2009 15:10:48 +0200

Lou,

That's was one of my WG LC comments.

Italo 

> From: Lou Berger [mailto:[email-masked]] 
> Sent: Wednesday, April 15, 2009 4:27 PM
> To: BUSI ITALO
> Cc: Maarten Vissers; Ben Niven-Jenkins; [email-masked]

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Apr 2009 09:49:22 -0400

Ahh, I missed that you were re-raising a comment that was rejected.  As 
Ben says, "all standards work it is about compromise"...

Thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 16 Apr 2009 09:43:09 -0400

Ben,
	It seems to me that much of the discussion stems from the section in 
which these requirements are listed.

Requirement 32 is a service level requirement and primarily impact the 
management and control planes.  As there is no section describing 
service requirements, I suggest moving this requirement to follow 
requirement 6, and adding the following in its place:
    33  MPLS-TP MUST support bidirectional transport paths with
        symmetric bandwidth requirements, i.e. the amount of reserved
        bandwidth is the same between the forward and backward
        directions.

While this too is a service requirement and doesn't require any hardware 
modifications, it parallels current requirements 37, 40 and 41.  It also 
makes a currently implicit requirement explicit.

Requirements 33-26 relate to "awareness" should have no implication on 
the data/forwarding plane and are IMO both management and control plane 
requirements. (And yes, they have implications on OAM and recovery.)  I 
think Adrian raises a good point WRT these requirements, i.e., are these 
requirements listed as solutions to some unlisted requirements.  If so, 
the unlisted requirements should be included and these should be 
dropped.  If not, so be it, but they should be moved from section 2.3.

While I'm sure this won't end the discussion, I think these changes will 
help make "the requirements clear enough ..."

Lou

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Apr 2009 16:57:04 +0200

Sasha,
 
transport networks support co-routed bidirectional P2P as well as
unidirectional P2P and P2MP paths.
 
In line with this obeservation, MPLS-TP MUST support co-routed
bidirectional P2P transport paths as well as unidirectional P2P and P2MP
transport paths.
 
As MPLS-TP is not only a transport technology but also a packet
terchnology, asymmetric BW allocation is required for MPLS-TP.
 
As a consequence, co-routed bidirectional P2P transport paths MUST
support asymmetric BW allocation as perfectly documented in Req.37.
 
The key issue is that I do not see requirements for associated
bidirectional P2P transport paths in MPLS-TP rather although I see
requirements for them only in traditional MPLS.
 
Italo

________________________________

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

	Adrian,

	My previous response to your message has been too long already
while dealing only with one item in this message.
	
	I'd like to add that I fully agree with what I perceive as the
other key statement in your message:

	<quote>

	     ("That" standing for "Experience with existing transport
networks rather than any specific benefit")
	     Which is not to say it is a bad thing.
	
the look, feel, and

	The only question here is, to what extent this experience and
these behavioral characteristics (which, to the best of my
understanding, mainly have dealt with P2P co-routed bidirectional paths
with symmetric BW allocation) can advance the proclaimed MPLS-TP goals,
which include:

	E.g., I suspect that the need for associated bidirectional paths
may be closely related to the need to support bidirectional paths with
asymmetric BW allocation...

	My 2c,

	     Sasha

	________________________________________
	From: [email-masked] [[email-masked]] On
Behalf Of Alexander Vainshtein [[email-masked]]
	Sent: Thursday, April 16, 2009 10:04 AM
	To: Adrian Farrel
	Cc: [email-masked]; ITALO; [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements
	
	Adrian,

	<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
	
(http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.
txt):
	
	<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>
	
	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.

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

draft
	
(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).
	
	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.
	
	My 2c,
	     Sasha

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

	
are a
	
management plane)
	
	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.
	
	> * they had a good chance to remain the only type of
bidirectional
	>   paths in  real deployments.

	Cheers,
	Adrian

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Apr 2009 17:05:10 +0200

> provides the necessary performance that the customer requires.

Correct: in fact we have already deployed traditional MPLS networks
providing transport services.

The fact that the server layer of a transport client layer does not
support co-routed bidirectional transport paths do not change the
co-routed bidirectional nature of the client layer transport path.

> today to support at least some transport network services 

I do not fully agree here.
My understanding of co-routed bidirectional paths was aligned with the
text in the -04 version:
   Co-routed bidirectional path: A bidirectional path where the forward
   and backward directions follow the same route (links and nodes)
   across its layer network.

In this case, an MS-PW is a co-routed bidirectional paths within the
MS-PW layer network. Its server layer (i.e. MPLS LSP) can carry such a
client either over a co-routed bidirectional LSP or an associated
bidirectional LSP or two unidirectional LSPs.

I just noticed that the actual definition of co-routed bidirectional
paths has been changed in the -06 version. I wonder whether I have
missed something.

Thanks, Italo

> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: Thursday, April 16, 2009 12:08 PM

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Apr 2009 17:09:18 +0200

Adrian,

I am not sure I fully understand your comments on Req.34.

I wonder whether moving it to the "General Requirements" section and
updating in line with your suggestion (see below) actually solve them:

Italo

> Sent: Thursday, April 16, 2009 11:59 AM
> Cc: [email-masked]; Lou Berger; BUSI ITALO
> > specific
> I-Ds into line.
> solutions have nothing

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Apr 2009 17:24:09 +0200

Adrian,

> TC seems to be at variance, and would be if the ACH was 

This is a strong requirement for transport networks and ITU-T has
clearly communicated this to IETF during the JWT analysis.

We will be very persistent in maintaining what has been agreed by the
JWT.

Italo

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 16 Apr 2009 19:41:15 +0300

Italo,

IMHO and FWIW the need for asymmetric BW allocation stems from the fact that predominant client traffic today uses asymmetric BW.

So the requirement to support asymmetric BW allocation in MPLS-TP is actually the requirement to accommodate the predominant client traffic without unnecessary waste of resources. The fact that MPLS, being a packet-based technology, is capable of doing that, means only that this requirement can be met; and the desire to use available resources effectively is, AFAIK, a major drive for switch packet-based transport.

At the same time I suspect that combining asymmetric BW allocation with co-routed bidirectional paths will result (again) in BW waste, since (physical) links used in transport networks presumably are symmetrical (I have not heard yet about MPLS-TP being run over ADSL:-). Removing the "co-routed" requirement provides a chance to improve BW utilization in the transport network.

The actual BW utilization gain may vary depending on actual client traffic distribution, so that the operator will have to decide on a per-case bases whether it justifies dropping some traditions and some (yet unspecified) advantages implied by these traditions.

Regards,

     Sasha

________________________________
From: BUSI ITALO [[email-masked]]
Sent: Thursday, April 16, 2009 5:57 PM
To: Alexander Vainshtein; Adrian Farrel
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Sasha,

transport networks support co-routed bidirectional P2P as well as unidirectional P2P and P2MP paths.

In line with this obeservation, MPLS-TP MUST support co-routed bidirectional P2P transport paths as well as unidirectional P2P and P2MP transport paths.

As MPLS-TP is not only a transport technology but also a packet terchnology, asymmetric BW allocation is required for MPLS-TP.

As a consequence, co-routed bidirectional P2P transport paths MUST support asymmetric BW allocation as perfectly documented in Req.37.

The key issue is that I do not see requirements for associated bidirectional P2P transport paths in MPLS-TP rather although I see requirements for them only in traditional MPLS.

Italo

From: Alexander Vainshtein [mailto:[email-masked]]

Adrian,

<quote>

My 2c,

     Sasha

Adrian,

<quote>

<quote>

<quote>

My 2c,
     Sasha

Hi Sasha,

Cheers,
Adrian

---

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

Maarten,
It seems that you've just (implicitly and, probably, inadvertently) stated the following:

MPLS-TP OAM will not ever support MIP loopback function (and fault localization which requires this function ) for unidirectional P2MP and P2P paths.

If this statement is correct, this (IMHO and FWIW) raises a valid question:

Is MPLS-TP an appropriate solution for these types of transport paths?

For the reference, IP/MPLS provides this kind of functionality today for (unidirectional - but it does not know any other type) P2P LSPs  as described in RFC 4379. And its extension to P2MP LSPs seems easy...

Regards,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Maarten Vissers [[email-masked]]
Sent: Thursday, April 16, 2009 3:24 PM
To: 'Adrian Farrel'
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Adrian,

internal

inclusion
poorly
tandem)
variance,

Regards,
Maarten

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

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:58:47 +0100

Adrian,

> If the authors do know what they mean, they should say it.

"as appropriate" is because I wrote the text of the requirement based on
asks for it to be a requirement from others and I didn't entirely know what
was being asked for so I took an educated guess.

What I was trying to do was highlight some of the functions in a node that
may make use of such information to try and add clarity as to how it may be
used. I have no problem removing the text if it doesn't add that clarity and
just leave as "The intermediate nodes of a co-routed..."

If other participants want the text kept then they need to propose
alternative text that is acceptable to our ADs as the current text is the
best I can come up with on my own.

Ben

---

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

Colleagues,

On 16/04/2009 17:41, "Alexander Vainshtein"
<[email-masked]> wrote:

> Italo,
> 
> IMHO and FWIW the need for asymmetric BW allocation stems from the fact that
> predominant client traffic today uses asymmetric BW.

Let's close this one on asymmetric bandwidth requirement.

It is a requirement because a large Tier 1 US operator publicly stated on
this list they had a requirement for it.

You can debate its use and applicability to death when it comes to defining
solutions. For the requirements draft, it is a real operator requirement and
that's all we need to worry about at this time unless anyone feels the text
of the requirement is not clear.

Ben

P.S. Sasha, although I replied to your mail my comment is not directed
specifically at you.

---

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

Snipped... 

> 
> At the same time I suspect that combining asymmetric BW 
> allocation with co-routed bidirectional paths will result 
> (again) in BW waste, since (physical) links used in transport 
> networks presumably are symmetrical (I have not heard yet 
> about MPLS-TP being run over ADSL:-). Removing the 
> "co-routed" requirement provides a chance to improve BW 
> utilization in the transport network.

JD:  That's not necessarily the case.  There can be many asymmetric BW
bi-directional LSPs placed on a given link and it's unlikely that the
fat and skinny directions of each will line up.

---

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

http://www.ietf.org/internet-drafts/draft-ietf-mpls-remote-lsp-ping-03.t
xt 

> Sent: Thursday, April 16, 2009 9:57 AM
> To: Maarten Vissers
> Cc: [email-masked]
> 	MPLS-TP OAM will not ever support MIP loopback function 
> (and fault localization which requires this function ) for 
> unidirectional P2MP and P2P paths.
> 
> For the reference, IP/MPLS provides this kind of 
> functionality today for (unidirectional - but it does not 
> know any other type) P2P LSPs  as described in RFC 4379. And 
> its extension to P2MP LSPs seems easy...

JD:  See http://tools.ietf.org/html/draft-ietf-mpls-p2mp-lsp-ping-07 

and 

http://www.ietf.org/internet-drafts/draft-ietf-mpls-remote-lsp-ping-03.t
xt

At the meeting last fall at Juniper in Massachusetts, I think it was
agreed that an MPLS TP network needs to have a forwarding capability for
management, control, and OAM packets (e.g., sending replies to OAM
requests sent on uni-directional LSPs) even if it does not have an IP
forwarding data plane. 

> Behalf Of Maarten Vissers [[email-masked]]
> Your understanding is not correct. It is very much observable 
> if this requirement is met from a black box point of view. 
> The MIP functions can only perform the Loopback when there is 
> a co-routed bidirectional transport path. The MPLS-TP LBM 
> packet received at a MIP needs to be returned (as LBR
> packet) to the originating MEP function via the other 
> direction of the co-routed bidirectional transport path. This 
> other direction would not be available in an associated 
> bidirectional transport path... and thus the loopback test would fail.
> 
> segment, then this is possible in a co-routed bidir transport 
> path but not in a associated bidir transport path. In the 
> first case the TCM MEP Source and Sink functions are 
> co-located and can exchange what is called "remote 
> information" which is necessary for performance monitoring. 
> In the latter case the TCM MEP Source and Sink functions are 
> in e.g. different nodes in the network and TCM would not be 
> able to provide performance monitoring.
> 
> > of "Tandem Connection." The definition within the ITU-T of 
> this term 
> > is
> poorly
> I don't understand where your interpretation of tandem 
> connection is described in ITU-T recommendations. I.e. "from 
> the monitoring of a path that is parallel (i.e. tandem) to 
> the data path being monitored."?
> 
> There is a "network connection" and this network connection 
> is a set of interconnected "link connections" and "matrix 
> connections". A subset of those interconnected link 
> connections and matrix connections can be monitored and is 
> then referred to as a "tandem connection". There is no "path 
> that is parallel to the data path". There is only additional 
> OAM inserted inside the data path by the TCM MEP_So function 
> and this OAM is extracted from the data path by the TCM 
> MEP_Sk function.
> 
> Regards,
> Maarten
> 
> 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Requirement
> *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".
> 
> 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."
> 
> 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.
> 
> created in 
> LSPs are a special case of associated bidirectional LSPs.
> 
> management plane) you can surely set up a co-routed bidirectional LSP.
> 
> bidirectional LSPs using the control plane. These either use 
> the GMPLS (which is cleaner) or non-standard proprietary 
> solutions (which is messy but functional).
> 
> solutions have nothing to do with availability of equipment 
> as they are software solutions.
> 
> look, feel, and behavioral characteristics of a "legacy" 
> transport network.
> 
> 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.
>

---

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

---

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

John,
Lots of thanks for pointing to the P2MP LSP Ping draft. I have been pretty sure it exists but did not find it when responding to Maarten.

Regards,
     Sasha

________________________________________
From: Drake, John E [[email-masked]]
Sent: Thursday, April 16, 2009 8:48 PM
To: Alexander Vainshtein; Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

and

---

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

Why don't we use 'and lots of other important technical stuff' instead? 

> Sent: Thursday, April 16, 2009 9:59 AM
> To: Adrian Farrel; Maarten Vissers
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Requirement 34 and TCM[Was: Associated 
> authors do 
> > not know what they mean and have used the phrase to avoid 
> working it out, then it needs to be fixed.
> "as appropriate" is because I wrote the text of the 
> requirement based on asks for it to be a requirement from 
> others and I didn't entirely know what was being asked for so 
> I took an educated guess.
> 
> What I was trying to do was highlight some of the functions 
> in a node that may make use of such information to try and 
> add clarity as to how it may be used. I have no problem 
> removing the text if it doesn't add that clarity and just 
> leave as "The intermediate nodes of a co-routed..."
> 
> If other participants want the text kept then they need to 
> propose alternative text that is acceptable to our ADs as the 
> current text is the best I can come up with on my own.
> 
> Ben
>

---

From: [email-masked]
Date: Fri, 17 Apr 2009 09:15:30 +0800

Lou:
 I agree your advice, but for symmetric bandwidth requirement, I think the 
requirement can only be fit for co-routed bidirectional transport paths, 
while it isn't necessary for associated bidirectional paths .so adding a 
"co-routed"  word in the requirement 33 is necessary.
thank you.
liu

Lou Berger <[email-masked]> 
发件人:  [email-masked]
2009-04-16 21:43

收件人
Ben Niven-Jenkins <[email-masked]>
抄送
[email-masked], "[email-masked]" <[email-masked]>, ITALO 
<[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Ben,
                 It seems to me that much of the discussion stems from the 
section in 
which these requirements are listed.

Lou

>> This statement would be obviously correct, were it not for Requirement 
34 in
>> the latest
>> (
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-06.txt
transport
specific
bidirectional
>> (
http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-01.tx

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

--------------------------------------------------------
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: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Apr 2009 02:35:39 +0100

Italo,

In turn I am a little worried by your statement.

> We will be very persistent in maintaining what has been agreed by the

While our aim is to follow the JWT agreement I do not think we should
blindly follow it because it was agreed by the JWT. As our understanding of
MPLS-TP and its requirements evolves so it may be that some things agreed by
the JWT are no longer relevant.

Remember when the JWT made its agreement the requirements for T-MPLS/MPLS-TP
were in general poorly specified and therefore I have to assume some
assumptions had to be made. With all assumptions there is risk that although
they were the best available assumption at the time that subsequently they
are shown to be incorrect.

So, IMO, something is not a requirement because the JWT agreed it. It is a
requirement because operators require it.

If operators require it then fine, but I have yet to hear an operator state
publicly either in ITU or IETF that they require TCM in MPLS-TP.

Like I said earlier tonight I know not all operators participate in
standards but if just one operator were to step forward and say they require
TCM it would put an end to this debate.

Ben

---

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

Ben,

For me the proposal from Adrian (i.e. removing the text within brackets)
is fine.

Italo

> Sent: Thursday, April 16, 2009 6:59 PM
> bidirectional transport path requirements]
> 
> Adrian,
> 
> appropriate" is
> requirement based on
> in a node that

---

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

Ben,

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.

We have never agreed to evaluate which requirement has to be meet and
which has not. The expectation is that all the ITU-T requirements will
be met.

Italo

> Sent: Friday, April 17, 2009 3:36 AM
> To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein
> Cc: [email-masked]; Lou Berger
> Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] 
> Associated bidirectional transport path requirements)
> 
> Italo,
>

---

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

John,

I might have missed the agreement of MPLS-TP being capable of sending
replies to OAM requests sent on uni-directional LSPs.

This requirement does not belong to the first set of requirements ITU-T
is expecting to be met by October.

However, I think this in a potential interesting additional requirement
to be taken into account (at worst in a subsequent phase).

I think that this requirement needs to be evaluated versus other more
important requirements (e.g. the possibility to work w/o IP forwarding
and the need for OAM to continue to monitor the data plane also in case
of failures affecting the control or management plane).

I am open to discuss it but not sure this is the right time because I
wish to avoid delaying the first phase of the design solution.

Thanks, Italo

> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: Thursday, April 16, 2009 8:00 PM

---

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

Lou,

Looking at the on-going discussion I would call it "not-yet resolved"
comment

;-)

Italo 

> [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Thursday, April 16, 2009 3:49 PM
> To: BUSI ITALO
> Cc: [email-masked]

---

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

Lou,

I am not 100% sure we have a common understanding of what "service level
requirement" means.

However, I agree with your proposal to move requirements 32-37 in
section 2.1 (e.g. after Req.6) as well as to explicitly add the
requirement for symmetric BW support.

The only point that we still need to address is that we need to clarify
that associated bidirectional paths are not required in transport
networks but in traditional MPLS networks.

Italo

> Sent: Thursday, April 16, 2009 3:43 PM
> To: Ben Niven-Jenkins
> Cc: Alexander Vainshtein; Adrian Farrel; BUSI ITALO; 
> [email-masked]; [email-masked]
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-re
> quirements-01.tx
> >> t)
> >> 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
> given that other

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Apr 2009 10:21:40 +0100

Italo,

> 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

---

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

Ben,

I think we are mixing solutions with requirements.

The requirement for the TCM function is clearly defined and I do think
it must be addressed by the MPLS-TP design.

The solution evaluated by the JWT to meet this requirement was to use
label stacking with a 1:1 relationship between the TCM LSP and the e2e
LSP.

I think this solution, although not the best technical option, is good
enough and meets the requirements.

However this is is a solution and has not impact on the requirement.

Italo

> Sent: Friday, April 17, 2009 11:22 AM

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Apr 2009 11:04:17 +0100

Italo,

I think we are converging. If I can be so bold as to speak on his behalf
Adrian's objection seemed to be to the use of the term TCM.

It is defined in the MPLS-TP requirements but not used.

It is not used in the MPLS-TP OAM requirements document.

Therefore I think the way forward is as follows:

1) Remove the term Tandem Connection from the MPLS-TP requirements as it is
redundant (i.e. Not used in that document).

2) Ensure the MPLS-TP OAM requirements express the necessary functional
requirements around monitoring of end to end paths as well as parts of end
to end paths. This can be done without referring explicitly to Tandem
Connections.

When it comes to solution design we can decide what is the best mechanism to
achieve/implement those requirements be it LSP hierarchy or something else.
The JWT has proved that it is possible to meet those requirements using
existing MPLS technology (maybe with some enhancements). I do not believe we
have to necessarily use the solution they propose aslong as whatever
solution we ultimately decide upon meets all the necessary requirements
expressed.

Can we agree on that as an approach and close this off for now?

Ben

---

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

Ben,

Well captured.

That would work for me.

A
----- Original Message ----- 
From: "Ben Niven-Jenkins" <[email-masked]>
To: "BUSI ITALO" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; "Alexander Vainshtein" 
<[email-masked]>
Cc: <[email-masked]>; "Lou Berger" <[email-masked]>
Sent: Friday, April 17, 2009 11:04 AM
Subject: Re: Tandem Connections in MPLS-TP (was RE: [mpls-tp] Associated 
bidirectional transport path requirements)

---

From: Loa Andersson <[email-masked]>
Date: Fri, 17 Apr 2009 13:14:31 +0200

Ben,

this would work for me

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Fri, 17 Apr 2009 04:11:42 -0700

This would work for me

/Loa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Friday, April 17, 2009 12:04 PM
To: BUSI ITALO; Adrian Farrel; Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements)

Italo,

Ben

---

From: Martin Vigoureux <[email-masked]>
Date: Fri, 17 Apr 2009 13:28:33 +0200

Ben, all

in mpls-tp-oam-requirement, the text on this item is as follows:

    The service emulated by a single segment or a multi-segment PW may
    span multiple domains.  A LSP may also span multiple domains.  It
    MUST be possible to perform OAM functions on a per domain basis and
    across multiple domains.  More generally it MUST be possible to
    perform OAM functions between any two switching elements (e.g., LSR
    or S-PE) of a LSP or of PW.  This is referred to as (concatenated)
    segment monitoring.

I believe the text describes a functional req.

During mead team review, the removal of the last sentence was discussed.
No strong opinion was expressed on whether it should effectively be
removed or not.

regards,
martin

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 17 Apr 2009 12:38:04 +0100

Martin,

This is a good example of how to write a functional requirement. Thanks!

Adrian
----- Original Message ----- 
From: "Martin Vigoureux" <[email-masked]>
To: "Ben Niven-Jenkins" <[email-masked]>
Cc: "BUSI ITALO" <[email-masked]>; "Adrian Farrel" 
<[email-masked]>; "Alexander Vainshtein" 
<[email-masked]>; <[email-masked]>
Sent: Friday, April 17, 2009 12:28 PM
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated 
bidirectional transport path requirements)

---

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

Hi all,
sorry but I do not understand why we cannot explicitly use the term Tandem Connection in the requirements document!
TCM is not a solution, it is part of functional architecture of a transport networks as described in G.805. The solution is to realize it with label stacking rather than MEL. 

Regards
Annamaria
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Vigoureux
Sent: venerdì 17 aprile 2009 13.29
To: Ben Niven-Jenkins
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements)

Ben, all

During mead team review, the removal of the last sentence was discussed.
No strong opinion was expressed on whether it should effectively be removed or not.

regards,
martin

Ben Niven-Jenkins a écrit :
> Italo,
> 
> I think we are converging. If I can be so bold as to speak on his 
> behalf Adrian's objection seemed to be to the use of the term TCM.
> 
> 1) Remove the term Tandem Connection from the MPLS-TP requirements as 
> it is redundant (i.e. Not used in that document).
> 
> 2) Ensure the MPLS-TP OAM requirements express the necessary 
> functional requirements around monitoring of end to end paths as well 
> as parts of end to end paths. This can be done without referring 
> explicitly to Tandem Connections.
> 
> When it comes to solution design we can decide what is the best 
> mechanism to achieve/implement those requirements be it LSP hierarchy or something else.
> The JWT has proved that it is possible to meet those requirements 
> using existing MPLS technology (maybe with some enhancements). I do 
> not believe we have to necessarily use the solution they propose 
> aslong as whatever solution we ultimately decide upon meets all the 
> necessary requirements expressed.
> 
>> The requirement for the TCM function is clearly defined and I do 
>> think it must be addressed by the MPLS-TP design.
>>
>> label stacking with a 1:1 relationship between the TCM LSP and the 
>> e2e LSP.
>>
>> I think this solution, although not the best technical option, is 
>> good enough and meets the requirements.
>>
>>> " 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?
>>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 17 Apr 2009 09:54:41 -0400

Liu,
	Why isn't it necessary for associated bidirectional paths?  Is it that
asymmetric is the sole requirement?  If not, I don't understand your
comment.

Lou

On 4/16/2009 9:15 PM, [email-masked] wrote:
> 
> Lou:
> I agree your advice, but for symmetric bandwidth requirement, I think 
> the requirement can only be fit for co-routed bidirectional transport 
> paths, while it isn't necessary for associated bidirectional paths .so 
> adding a "co-routed" word in the requirement 33 is necessary.
> thank you.
> liu
> 
> 
> *Lou Berger <[email-masked]>*

---

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

+1 

> From: Annamaria Fulignoli [mailto:[email-masked]] 
> Sent: Friday, April 17, 2009 1:52 PM
> To: VIGOUREUX MARTIN; Ben Niven-Jenkins
> Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP (was RE: 
> sorry but I do not understand why we cannot explicitly use 
> the term Tandem Connection in the requirements document!
> TCM is not a solution, it is part of functional architecture 
> of a transport networks as described in G.805. The solution 
> is to realize it with label stacking rather than MEL. 
> 
> Regards
> Annamaria
> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Apr 2009 15:26:11 +0100

Because IMO use of the term TCM tends to make people think of a particular
solution and what we want to do at this stage is express the functional
requirements and not imply any particular solution.

Certainly most of my mails in this thread (and I am probably not the only
one) have been based on the fact that when discussing TCM I assume a
particular solution is being discussed. Talking purely in terms of
functional requirements removes that ambiguity.

Ben

On 17/04/2009 12:51, "Annamaria Fulignoli"
<[email-masked]> wrote:

> TCM is not a solution, it is part of functional architecture of a transport
> networks as described in G.805. The solution is to realize it with label
> stacking rather than MEL.
> 
> Regards
> Annamaria

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 17 Apr 2009 10:59:13 -0400

I agree with Ben. TCM, with the introduction of MEL as a solution, has become architecturally confusing. When it was used in reference to SDH, where trail overhead was overwritten, it created a tandem connection. For cell/packet technologies where the OAM cells/packets are inserted, it is not clear if this is a tandem connection or a new server layer, as both architectural terms are used in the standards. 

In G803, TCM is a sublayer monitoring technique for a SDH tandem connection:
"Sublayer monitoring
Connections may be directly monitored at one end of a connection by overwriting some portion of the original trail's overhead capacity at the beginning of the connection. For SDH, overhead has been defined for this purpose at the higher-order and lower-order path layers. When applied to a SDH tandem connection, this monitoring method is referred to as tandem connection monitoring."

Whereas in Y.1711:
"OAM techniques are applied on a per LSP basis. If a segment of a given LSP at layer N is to be monitored for some reason (e.g., via a CV or P flow say), one way to do this is by creating a new server layer LSP (i.e., at layer N + 1) to cover the segment at layer N."

So I think before using TCM in reference to MPLS-TP, Q12 needs to align on the use. For now, the requirements documents should try to avoid it.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Friday, April 17, 2009 10:26 AM
To: Annamaria Fulignoli; Martin Vigoureux
Cc: BUSI ITALO; [email-masked]
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated bidirectional transport path requirements)

Ben

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 16:21:38 +0100

I agree with both Ben and Deborah.  One further point to add here.....

G.805 is a fairly old Recommendation written largely to give us a working func arch language for the development of management information models when we were developing SONET/SDH.  However, our understanding of the physics of networking has improved significantly and G.800 (Unified functional architecture of transport networks) is a more comprehensive embodiment of that understanding that covers all 3 network modes (based on sound Info and Systems theory underpinnings).  So G.800 should be the starting point for any references to the network func architecture for MPLS-TP and not G.805 IMO.

regards, Neil

> [mailto:[email-masked]] On Behalf Of BRUNGARD, 
> DEBORAH A, ATTLABS
> Sent: 17 April 2009 15:59
> To: Niven-jenkins,B,Ben,DMF R; Annamaria Fulignoli; Martin Vigoureux
> Associatedbidirectional transport path requirements)
> 
> I agree with Ben. TCM, with the introduction of MEL as a 
> solution, has become architecturally confusing. When it was 
> used in reference to SDH, where trail overhead was 
> overwritten, it created a tandem connection. For cell/packet 
> technologies where the OAM cells/packets are inserted, it is 
> not clear if this is a tandem connection or a new server 
> layer, as both architectural terms are used in the standards. 
> 
> Connections may be directly monitored at one end of a 
> connection by overwriting some portion of the original 
> trail's overhead capacity at the beginning of the connection. 
> For SDH, overhead has been defined for this purpose at the 
> higher-order and lower-order path layers. When applied to a 
> SDH tandem connection, this monitoring method is referred to 
> as tandem connection monitoring."
> 
> Whereas in Y.1711:
> "OAM techniques are applied on a per LSP basis. If a segment 
> of a given LSP at layer N is to be monitored for some reason 
> (e.g., via a CV or P flow say), one way to do this is by 
> creating a new server layer LSP (i.e., at layer N + 1) to 
> cover the segment at layer N."
> 
> So I think before using TCM in reference to MPLS-TP, Q12 
> needs to align on the use. For now, the requirements 
> documents should try to avoid it.
> 
> Deborah
> 
> > No strong opinion was expressed on whether it should 
> effectively be removed or
> > not.
> > 
> > regards,
> > martin
> > 
> >> mechanism to achieve/implement those requirements be it 
> LSP hierarchy or
> >> something else.

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 17 Apr 2009 13:15:23 -0500

Lou/Italo,

	This gets into a fuzzy language area.

	I think it should be clear that use of associated
(non-co-routed)
bi-directional paths is not required.  It also seems to me to be clear 
that they might be used; hence support for them is needed in protocols
and other specifications.

	We all need to be precise in what we mean by what is required,
and where it is required.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Lou Berger
Sent: Wednesday, April 15, 2009 10:27 AM
To: BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

Italo,

Lou

---

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

Ben,

TCM is an architectural construct well defined in G.805 in a technology-independent manner. As such TCM does not imply any specific solution.

The solution we are working on to implement TCM within MPLS-TP is based on the JWT agreement and described in the OAM Framework document.

I do not think we should drop a requirement because of people's misunderstandings.

Italo

> Sent: Friday, April 17, 2009 4:26 PM
> To: Annamaria Fulignoli; VIGOUREUX MARTIN

---

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

Neil,

G.805 is an in-force Recommendation: G.800 was never intended to replace G.805.

People who worked on G.800 has always claimed that for connection-oriented technologies G.800 defaults to G.805.

When Q12/15 consented G.800, it was agreed that existing Recommendations based on G.805 (e.g. G.8110.1) will continue to be based on G.805.

Italo

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, April 17, 2009 5:22 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; VIGOUREUX MARTIN
> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was 
> RE:Associatedbidirectional transport path requirements)
> 
> G.805 is a fairly old Recommendation written largely to give 
> us a working func arch language for the development of 
> management information models when we were developing 
> SONET/SDH.  However, our understanding of the physics of 
> networking has improved significantly and G.800 (Unified 
> functional architecture of transport networks) is a more 
> comprehensive embodiment of that understanding that covers 
> all 3 network modes (based on sound Info and Systems theory 
> underpinnings).  So G.800 should be the starting point for 
> any references to the network func architecture for MPLS-TP 
> and not G.805 IMO.
> 
> regards, Neil
>

---

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

Eric,

You got exactly the spirit of my comment.

Italo

> From: Eric Gray [mailto:[email-masked]] 
> Sent: Friday, April 17, 2009 8:15 PM
> To: Lou Berger; BUSI ITALO
> Cc: [email-masked]

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 17 Apr 2009 12:02:10 -0700

Italo,

As described in the MPLS TP OAM Requirements I-D, virtually all of the
OAM functions require a return path, and in the absence of a return path
they are disabled.

As described in David Sinicrope's meeting minutes
(http://wiki.tools.ietf.org/misc/mpls-interop/attachment/wiki/meeting-no
tes/20081015.mpls-interop-dt-notes.zip), if IP addressing is used, an
MPLS TP network needs to be capable of getting IP packets from
destination to source; neither the minutes nor I stipulate that a
control plane needs to be used to instantiate this forwarding.

As an aside, the issue of return path for unidirectional LSPs could be
charaterized as the elephant in the room.  In the MPLS TP OAM Framework
I-D, unicast LSPs are only mentioned three times and return paths not at
all.  

Thanks,

John
> From: BUSI ITALO [mailto:[email-masked]] 
> Sent: Friday, April 17, 2009 1:59 AM
> To: Drake, John E; Alexander Vainshtein; Maarten Vissers
> Cc: [email-masked]
> I might have missed the agreement of MPLS-TP being capable of 
> sending replies to OAM requests sent on uni-directional LSPs.
> 
> This requirement does not belong to the first set of 
> requirements ITU-T is expecting to be met by October.
> 
> However, I think this in a potential interesting additional 
> requirement to be taken into account (at worst in a subsequent phase).
> 
> I think that this requirement needs to be evaluated versus 
> other more important requirements (e.g. the possibility to 
> work w/o IP forwarding and the need for OAM to continue to 
> monitor the data plane also in case of failures affecting the 
> control or management plane).
> 
> I am open to discuss it but not sure this is the right time 
> because I wish to avoid delaying the first phase of the 
> design solution.
> 
> Thanks, Italo
> 
> > agreed that an MPLS TP network needs to have a forwarding 
> capability 
> > for management, control, and OAM packets (e.g., sending 
> replies to OAM 
> (and fault 
> > > localization which requires this function ) for 
> unidirectional P2MP 
> > > and P2P paths.
> > > 
> functionality today 
> > > for (unidirectional - but it does not know any other 
> type) P2P LSPs  
> > > as described in RFC 4379. And its extension to P2MP LSPs seems 
> > > easy...
> > > 
> > >  
> > > 
> > > Regards,
> > > 
> > >      Sasha
> > > 
> > > 
> > > 
> > > From: [email-masked] [[email-masked]] 
> On Behalf 
> > > Of Maarten Vissers [[email-masked]]
> > > Your understanding is not correct. It is very much observable if 
> > > this requirement is met from a black box point of view.
> > > The MIP functions can only perform the Loopback when there is a 
> > > co-routed bidirectional transport path. The MPLS-TP LBM packet 
> > > received at a MIP needs to be returned (as LBR
> direction of 
> > > the co-routed bidirectional transport path. This other direction 
> > > would not be available in an associated bidirectional transport 
> > > path... and thus the loopback test
> > would fail.
> > > 
> segment, then 
> > > this is possible in a co-routed bidir transport path but not in a 
> > > associated bidir transport path. In the first case the TCM MEP 
> > > Source and Sink functions are co-located and can exchange what is 
> > > called "remote information" which is necessary for performance 
> > > monitoring.
> > > In the latter case the TCM MEP Source and Sink functions 
> are in e.g. 
> > > different nodes in the network and TCM would not be able 
> to provide 
> > > performance monitoring.
> > > 
> > > Your understanding is not correct. This text must not be 
> deleted at 
> > > all.
> > > 
> connection is 
> monitoring of a 
> > > path that is parallel (i.e. tandem) to the data path being 
> > > monitored."?
> > > 
> > > There is a "network connection" and this network 
> connection is a set 
> > > of interconnected "link connections" and "matrix connections". A 
> > > subset of those interconnected link connections and matrix 
> > > connections can be monitored and is then referred to as a "tandem 
> > > connection". There is no "path that is parallel to the 
> data path". 
> > > There is only additional OAM inserted inside the data path by the 
> > > TCM MEP_So function and this OAM is extracted from the 
> data path by 
> > > the TCM MEP_Sk function.
> > > 
> > > Regards,
> > > Maarten
> > > 
> > > 
> > > management plane. The database component is not used for anything 
> > > except to satisfy this requirement for "awareness".
> > > 
> > > 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 
> Framework 
> > co-routed vs.
> > > From the point of view of hardware, co-routed 
> bidirectional LSPs are 
> > > a special case of associated bidirectional LSPs.
> > > 
> > > 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).
> > > 
> > > nothing to do with availability of equipment as they are software 
> > > solutions.
> > > 
> the look, 
> > > feel, and behavioral characteristics of a "legacy"
> > > transport network.
> > > 
> given that 
> > > other upgrades to existing MPLS solutions will be needed to reach 
> > > the full function level of MPLS-TP.
> > >

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 17 Apr 2009 12:06:36 -0700

> Sent: Friday, April 17, 2009 11:29 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; 
> Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP 
> (wasRE:Associatedbidirectional transport path requirements)
> 
> Neil,
> 
> People who worked on G.800 has always claimed that for 
> connection-oriented technologies G.800 defaults to G.805.

JD:  Connection-oriented circuit or connection-oriented packet technologies?

> 
> When Q12/15 consented G.800, it was agreed that existing 
> Recommendations based on G.805 (e.g. G.8110.1) will continue 
> to be based on G.805.
> 
> Italo
> 
> > G.805 is a fairly old Recommendation written largely to give us a 
> > working func arch language for the development of management 
> > information models when we were developing SONET/SDH.  However, our 
> > understanding of the physics of networking has improved 
> significantly 
> > and G.800 (Unified functional architecture of transport 
> networks) is a 
> > more comprehensive embodiment of that understanding that 
> covers all 3 
> > network modes (based on sound Info and Systems theory 
> underpinnings).  
> > So G.800 should be the starting point for any references to the 
> > network func architecture for MPLS-TP and not G.805 IMO.
> > 
> > regards, Neil
> > 
> DEBORAH A, 
> > > ATTLABS
> solution, 
> > > has become architecturally confusing. When it was used in 
> reference 
> > > to SDH, where trail overhead was overwritten, it created a tandem 
> > > connection. For cell/packet technologies where the OAM 
> cells/packets 
> > > are inserted, it is not clear if this is a tandem connection or a 
> > > new server layer, as both architectural terms are used in the 
> > > standards.
> > > 
> connection by 
> > > overwriting some portion of the original trail's overhead 
> capacity 
> > > at the beginning of the connection.
> > > higher-order and lower-order path layers. When applied to a SDH 
> > > tandem connection, this monitoring method is referred to 
> as tandem 
> > > connection monitoring."
> > > 
> > > Whereas in Y.1711:
> > > "OAM techniques are applied on a per LSP basis. If a segment of a 
> > > given LSP at layer N is to be monitored for some reason 
> (e.g., via a 
> > > CV or P flow say), one way to do this is by creating a new server 
> > > layer LSP (i.e., at layer N + 1) to cover the segment at layer N."
> > > 
> > > So I think before using TCM in reference to MPLS-TP, Q12 needs to 
> > > align on the use. For now, the requirements documents 
> should try to 
> > > avoid it.
> > > 
> > > Deborah
> > > 
> > > Because IMO use of the term TCM tends to make people think of a 
> > > particular solution and what we want to do at this stage 
> is express 
> > > the functional requirements and not imply any particular solution.
> > > 
> > > Certainly most of my mails in this thread (and I am 
> probably not the 
> > > only
> > > RE: Associated

---

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

Both

Italo 

> From: Drake, John E [mailto:[email-masked]] 
> Sent: Friday, April 17, 2009 9:07 PM
> To: BUSI ITALO; [email-masked]; [email-masked]; 
> Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP 
> > > > In G803, TCM is a sublayer monitoring technique for a 
> SDH tandem 
> > > > connection:
> > > > "Sublayer monitoring

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 20:25:19 +0100

Thanks Italo....I understand why you say this.  But I also work closely with Andy Reid who is the major driving force behind G.800 (and one of the folks who wrote the initial version of G.805) and it is very clear to me that the concepts that underpin G.800 are vastly superior to what we understood (as networking truths) at the time when G.805 was drafted.  But this (ie G.800) is a more general (and powerful) statement about how networks work and why we see the networking world as we do, ie 3 modes, etc.  And IMO it shoots down some sacred networking cows which is why some folks don't like it and appeal back to the good-old G.805 days.

TCM is a specific issue related to OAM.  And to repeat what I said earlier, I know of no engineer here in BT (this includes folks like Andy Reid, Alan McGuire, Ben Niven-Jenkins, me (obviously) etc) who think TCM is a good idea....quite the opposite in fact.  When we wrote a systems engineering spec for PBB-TE a while back there was no mention of TCM, and we would hold the same view for MPLS-TP.....there are far smarter ways to deal with rare on-demand OAM diagnostics.  So the mere fact that the term TCM appears in G.805 does not vindicate it's value in any way IMO.

I know you sidestepped my observation on TCM and IP, but if one is seriously suggesting TCM is such a great idea in IETF then it ought to figure in IP even before it gets considered for MPLS-TP IMO.....but I strongly suspect it never will and I think I also know why that would be.

regards, Neil

> Sent: 17 April 2009 19:29
> To: Harrison,N,Neil,CXM R; [email-masked]; 
> Niven-jenkins,B,Ben,DMF R; [email-masked]; 
> VIGOUREUX MARTIN
> Cc: [email-masked]
> Subject: RE: [mpls-tp] Tandem Connections in MPLS-TP (was

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 21:00:17 +0100

John,  Thanks this is a great platform to explain why OAM for the 3
network modes needs to be different.  I am getting a wee bit tired of
folks trying to make all 3 network modes look alike (and then, even
worse, interwork them as as peers...esp when not not top-of-stack
networks...I mean how silly can we get?).   I am even more frustrated by
the fact those peddling this FUD only ever seem to consider OAM and
forget all other DP/CP/MP components (esp top-of-stack
message/file/stream application adaptations).  How wrong can this get! 

In the co modes a *connection* is a very specific and *constraining*
construct.....I am assuming here we respect the rules of a connection
(ie single source) though some folks don't even bother to respect this,
and this is despite the fact that we all know what problems
multiple-source constructs can cause (from LDP/PHP....ergo MPLS-TP).

When we have a connection this restricts *all* DP (ie traffic and OAM)
to stay within the bounds of the connection.  Which is fine under
defect-free conditions, but if we have leaking traffic then the
constraining nature of the connection construct is broken.  In a
nutshell what this means is that OAM that is of a request/response
nature cannot be trusted in co mode networks under misconnectivity
defects.....indeed, why should a leaking DP have a symmetric go/return
defect behaviour?....very likely it won't.  So whilst request/response
OAM is right for the cl mode it is not right for the co mode under
misconnectivity defect conditions.

More generally the 3 modes are different and not just in OAM
requirements....but AIS/FDI in the cl mode?...do me a favour!...at least
IEEE had the good sense to bin this for Ethernet even though it remains
in Y.1731.  And which is why I often trot-out the rather silly (to have
to say this) observation that if IP (cl mode) could do it all then why
have IETF found it necessary to create MPLS (co-ps) and GMPLS (CP for
co-cs).  The answer lies in the physics...and G.800 attempts to explain
that physics....G.805 does not.

So, the 3 modes are different...please accept/rejoice in this fact as
they all offer something different/important.  But do not be hoodwinked
by those who peddle a story that that tries to make the OAM of the 3
modes the same. 

regards, Neil 

> Sent: 17 April 2009 20:02
> To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers
> Cc: [email-masked]
> > > > If this statement is correct, this (IMHO and FWIW) 
> raises a valid 
> > > > question:
> > > > 
> > > > 	Is MPLS-TP an appropriate solution for these 
> types of transport 
> > > > paths?
> > > > 
> > > > Let's just get rid of an unnecessary term and bring all 
> the I-Ds 
> > > > into line.
> > > >

---

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

Thank you, Eric.
Well captured.

We should all note that the MPLS-TP requirements draft is not a set of 
requirements for things that must be implemented or deployed. It is a set of 
requirements for what protocol support must be specified.

As you say, associated bidirectional transport paths might be used, so 
protocol support must be specified.

But we should also observe that it is not necessary to provide the same 
level of function on an associated bidirectional LSP that we would provide 
on a corouted LSP. We can make that decision now. If there are somethings 
that are particularly hard to do with associated bidirectional LSPs, then 
perhaps we should observe that if you want that function you need to use a 
corouted LSP.

Adrian

----- Original Message ----- 
From: "Eric Gray" <[email-masked]>
To: "Lou Berger" <[email-masked]>; "BUSI ITALO" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 17, 2009 7:15 PM
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

---

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

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

>monitoring but it does not achieve it using nested PWs or PW levels.

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

---

From: Maarten Vissers <[email-masked]>
Date: Sat, 18 Apr 2009 19:20:12 +0200

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

==================== 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

>> 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 
>different nested levels seamlessly (path, segment, multiple segments)
>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).
>
>different components of an end to end path or is the requirement that 
>such monitoring MUST be achieved using nested LSPs?
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 18 Apr 2009 23:41:48 +0100

Italo,

On 17/04/2009 19:20, "BUSI ITALO" <[email-masked]> wrote:

> Ben,
> 
> TCM is an architectural construct well defined in G.805 in a
> technology-independent manner. As such TCM does not imply any specific
> solution.
> 
> The solution we are working on to implement TCM within MPLS-TP is based on the
> JWT agreement and described in the OAM Framework document.
> 

See my mail from Friday which I have copied below. I do not believe I am
suggesting removal of requirements but that we describe the requirements
without reference to what appears to be a somewhat controversial term.

As Adrian has repeatedly stated what is important is we accurately capture
the functional requirements.

Given that neither the MPLS-TP requirements nor the MPLS-TP OAM requirements
documents use the term TCM when describing the requirements I think this aim
is thoroughly achievable without dropping any requirements.

That way we can close this issue IMO.

Ben

> From: Benjamin Niven-Jenkins <[email-masked]>
> Date: Fri, 17 Apr 2009 11:04:17 +0100
> To: BUSI ITALO <[email-masked]>, Adrian Farrel
> <[email-masked]>, Alexander Vainshtein <[email-masked]>
> Cc: <[email-masked]>

---

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

Hi,
I think we already have a requirement to manage and monitor the network
at different nested levels (end-to-end, segment, link, etc.) and this
should be satisfactory. 
TCM or whatever is used to solve it should appear in the architecture
document. 
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Loa Andersson
Sent: Friday, April 17, 2009 2:15 PM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated
bidirectional transport path requirements)

Ben,

this would work for me

/Loa

> I think we are converging. If I can be so bold as to speak on his
behalf
> 1) Remove the term Tandem Connection from the MPLS-TP requirements as
it is
> 2) Ensure the MPLS-TP OAM requirements express the necessary
functional
> When it comes to solution design we can decide what is the best
mechanism to
using
>> The requirement for the TCM function is clearly defined and I do
think
>> label stacking with a 1:1 relationship between the TCM LSP and the
e2e
>> I think this solution, although not the best technical option, is
good
>>> I think the real discussion is therefore is the requirement to
monitor

-- 

Loa Andersson

                                       email:
[email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 19 Apr 2009 11:14:09 +0200

Hi,
As a functional element, it should be described in the architecture document.
In the requirement draft we have the requirement to manage the paths at different nested levels.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext BUSI ITALO
Sent: Friday, April 17, 2009 9:21 PM
To: Ben Niven-Jenkins; Annamaria Fulignoli; VIGOUREUX MARTIN
Cc: [email-masked]
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associatedbidirectional transport path requirements)

Ben,

Italo

---

From: [email-masked]
Date: Mon, 20 Apr 2009 09:00:27 +0800

lou:
    because The forward and backward directions are setup, monitored and 
protected independent in the associated bidirectional paths. it can't 
ensure and realize the symmetric bandwidth in two directional path.
or else , I MUST revise the definitions of associated bidirectional paths 
in mpls-tp requirements draft.

regards
liu 

2009-04-17 21:54

收件人
[email-masked]
抄送
Ben Niven-Jenkins <[email-masked]>, [email-masked]
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Liu,
                 Why isn't it necessary for associated bidirectional 
paths?  Is it that
asymmetric is the sole requirement?  If not, I don't understand your
comment.

Lou

functions

explicitly
>  >> If you can set up two unidirectional LSPs (e.g. using the management 

> LSPs using
>  >> But (of course) the management plane or control plane solutions have 

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

---

From: [email-masked]
Date: Mon, 20 Apr 2009 09:03:02 +0800

++1

"BUSI ITALO" <[email-masked]> 
发件人:  [email-masked]
2009-04-17 21:59

收件人
, "VIGOUREUX MARTIN" <[email-masked]>, "Ben 
Niven-Jenkins" <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE: Associated 
bidirectional transport path requirements)

+1 

> effectively be removed or not.
> 
> regards,
> martin
>

---

From: [email-masked]
Date: Mon, 20 Apr 2009 10:01:29 +0800

John：
 I don't completely agree your opinions. for unidirectional P2P and P2MP 
path, if there is no return path, how can sink points reply to source 
point's request packet? if there are some faults in the backward sections 
of this unidirectional path, the sink points will detects the defects, if 
no return path, how can the sink points notify the fault message to source 
points.
and so, I think if there is no return path, what happened to 
unidirectional P2P and P2MP ?
I think we consider the return path.

regards
liu

"Drake, John E" <[email-masked]> 
发件人:  [email-masked]
2009-04-18 03:02

收件人
"BUSI ITALO" <[email-masked]>, "Alexander Vainshtein" 
<[email-masked]>, "Maarten Vissers" 
<[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] Associated bidiroectional transport path requirements

Italo,

Thanks,

John
> > >            Is MPLS-TP an appropriate solution for these types of 
transport

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 20 Apr 2009 07:02:05 +0100

Liu,

> in mpls-tp requirements draft.

You are claiming that it is not possible for the end points of an associated
bidirectional path to ensure that both directions have the same bandwidth
attributes. This is clearly IMO incorrect.

Let's take a real world example to illustrate why it is incorrect. If it
were true then it would not be possible for example to support E1 PWs in
MPLS networks today. Such E1 PWs are successfully being used in MPLS
networks today to support customer services.

Ben

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 20 Apr 2009 10:12:51 +0300

+1
The fact that two directions of the path are se up independently should not - and, AFAIK, 
does not prevent the operator from explicitly requesting same BW for two unidirectional paths. 

My 2c,
	Sasha

> Sent: Monday, April 20, 2009 9:02 AM
> To: [email-masked]; Lou Berger
> Cc: [email-masked]
> >>                Re: [mpls-tp] Associated bidirectional 
> transport path
> > requirements
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> Ben,
> >>> & ITU-T without this level of analysis of the initial 
> requirements -
> >> a great
> >>> If we want to go into the nth level of detail on each 
> requirement we
> > will

---

From: [email-masked]
Date: Mon, 20 Apr 2009 15:27:02 +0800

Ben:
 you can wrongly understand my meaning , here I want to clarify it is 
unnecessary for associated bidirectional path to keep symmetric bandwidth 
in both forward and backward path.
maybe my expressing isn't  clarify to make you to diffultly understand it.
here I say sorry to all

regards
liu 

2009-04-20 14:02

收件人
<[email-masked]>, Lou Berger <[email-masked]>
抄送
<[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Liu,

> in mpls-tp requirements draft.

You are claiming that it is not possible for the end points of an 
associated
bidirectional path to ensure that both directions have the same bandwidth
attributes. This is clearly IMO incorrect.

Ben

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Mon, 20 Apr 2009 09:37:22 +0200

Eric,
I couldn't agree more!

Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: venerdì 17 aprile 2009 20.15
To: Lou Berger; BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Lou/Italo,

	I think it should be clear that use of associated
(non-co-routed)
bi-directional paths is not required.  It also seems to me to be clear that they might be used; hence support for them is needed in protocols and other specifications.

	We all need to be precise in what we mean by what is required, and where it is required.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Wednesday, April 15, 2009 10:27 AM
To: BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Italo,

> required in transport networks (e.g. MPLS-TP)

This doesn't match draft-ietf-mpls-tp-requirements-06.  Are you proposing dropping associated bidirectional path from the TP requirements document?

Lou

---

From: [email-masked]
Date: Mon, 20 Apr 2009 16:19:20 +0800

i support Annamaria, I should have the requirements of supporting 
associated bidirectional path in mpls-tp. but it is unnecessary to keep BW 
in both directional path.

regards
liu

"Annamaria Fulignoli" <[email-masked]> 
发件人:  [email-masked]
2009-04-20 15:37

收件人
"Eric Gray" <[email-masked]>, "Lou Berger" <[email-masked]>, 
"BUSI ITALO" <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Eric,
I couldn't agree more!

Annamaria 

-----Original Message-----
Of Eric Gray

Lou/Italo,

                 I think it should be clear that use of associated
(non-co-routed)
bi-directional paths is not required.  It also seems to me to be clear 
that they might be used; hence support for them is needed in protocols and 
other specifications.

                 We all need to be precise in what we mean by what is 
required, and where it is required.

--
Eric

-----Original Message-----
Of Lou Berger

Italo,

> required in transport networks (e.g. MPLS-TP)

This doesn't match draft-ietf-mpls-tp-requirements-06.  Are you proposing 
dropping associated bidirectional path from the TP requirements document?

Lou

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 20 Apr 2009 09:36:04 +0100

Liu,

If I understand correctly you are saying associated bi-directional paths can
support both symmetric and asymmetric bandwidth transport paths.

That is correct.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 20 Apr 2009 09:38:55 +0100

I refer my learned colleagues to the following paragraph in the MPLS-TP
requirements

   The requirements expressed in this document are for the behavior of
   the protocol mechanisms and procedures that constitute building
   blocks out of which the MPLS transport profile is constructed.  The
   requirements are not implementation requirements.

BTW we seem to go around this same loop every few weeks.

Ben

On 20/04/2009 08:37, "Annamaria Fulignoli"
<[email-masked]> wrote:

> bi-directional paths is not required.  It also seems to me to be clear that
> they might be used; hence support for them is needed in protocols and other
> specifications.
>

---

From: [email-masked]
Date: Mon, 20 Apr 2009 16:40:26 +0800

Ben:
 if associated bidirectional paths can support both symmetric and 
asymmetric bandthwidth transport paths, I think it is unnecessary to claim 
the requirement in mpls-tp. because there are only this two conditions : 
symmetric and asymmetric. can someone privide another conditions.

regards
liu

2009-04-20 16:36

收件人
<[email-masked]>
抄送
<[email-masked]>
主题

Liu,

If I understand correctly you are saying associated bi-directional paths 
can
support both symmetric and asymmetric bandwidth transport paths.

That is correct.

Ben

---

From: "Rolf Winter" <[email-masked]>
Date: Mon, 20 Apr 2009 10:51:08 +0200

Liu,

That would still make it a requirement. There is no harm in spelling it out. Vice versa, expressing something clearly makes a good requirement. Since this has been debated for quite a bit we will not have this discussion again in a few weeks time if we simply express this explicitly in the requirements.

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> Behalf Of [email-masked]
> Sent: Montag, 20. April 2009 10:40
> To: Ben Niven-Jenkins
> Cc: [email-masked]
> asymmetric bandthwidth transport paths, I think it is unnecessary to
> claim the requirement in mpls-tp. because there are only this two
> conditions : symmetric and asymmetric. can someone privide another
> conditions.
> 
> regards
> liu
> 
> 
> 
> 2009-04-20 16:36 收件人
> >>>                Re: [mpls-tp] Associated bidirectional transport
> path
> >> requirements
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Ben,
> >>>> & ITU-T without this level of analysis of the initial requirements
> -
> >>> a great
> >>>> If we want to go into the nth level of detail on each requirement
> we
> >> will
> end
> >>> points
> pairing
> >>> awareness
> vs.
> >> a
> have
> >>>>>> 2. My reading of one of Neil's messages is that the actual
> driver
> >> for
> >>>>>> co-routed
> look,
> >>> feel, and
> >>> other
> >> ZTE Information Security Notice: The information contained in this
> mail
> > is
> >> confidential. Recipients named above are obligated to maintain
> secrecy
> > and are
> >> you have received this email in error please notify the originator
> of
> > the
> 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.

---

From: Lou Berger <[email-masked]>
Date: Mon, 20 Apr 2009 07:26:42 -0400

Ben,
	I agree completely.

Lou

On 4/20/2009 2:02 AM, Ben Niven-Jenkins wrote:
> Liu,
> 
> 
> On 20/04/2009 02:00, "[email-masked]"<[email-masked]>  wrote:
> 
>> lou:
>> Lou Berger<[email-masked]>
>> 2009-04-17 21:54
>>
>> 收件人
>> [email-masked]
>> 抄送
>> Ben Niven-Jenkins<[email-masked]>, [email-masked]
>> 主题
>>> *Lou Berger<[email-masked]>*
>>>                 Ben Niven-Jenkins<[email-masked]>
>>> 抄送

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 20 Apr 2009 05:48:38 -0700

liu,

Please re-read my e-mail.  You are agreeing with me.

Thanks,

John

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Sunday, April 19, 2009 7:01 PM
> To: Drake, John E
> Cc: [email-masked]
>  I don't completely agree your opinions. for unidirectional 
> P2P and P2MP path, if there is no return path, how can sink 
> points reply to source point's request packet? if there are 
> some faults in the backward sections of this unidirectional 
> path, the sink points will detects the defects, if no return 
> path, how can the sink points notify the fault message to 
> source points. 
> 2009-04-18 03:02 收件人
> "BUSI ITALO" <[email-masked]>, "Alexander 
> Vainshtein" <[email-masked]>, "Maarten 
> Vissers" <[email-masked]> 
> 抄送
> [email-masked] 
> 主题
> > > >                  Is MPLS-TP an appropriate solution for 
> these types of transport 
> > > > paths?
> > > > 
> > > > driver for
> 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.
> 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.

---

From: "Maarten Vissers" <[email-masked]>
Date: Mon, 20 Apr 2009 15:23:56 +0200

Neil,

> When we wrote a systems engineering spec for PBB-TE a while back there was
no mention of TCM,

If I understand PBB-TE, then the TESI in PBB-TE provides a tunnel which
starts/ends at e.g. metro domain edges (802.1Qay PAR states that PBB-TE is
defined for single domain usage only). 

Furthermore, TESI protection is provided using TESI trail OAM; essentially
the client signals carried by the TESI are protected as group using inherent
monitoring. In G.808.1 this is referred to as CL-SNCG/I protection. 

Because of the above there is indeed no need for TCM in PBB-TE TESI
connections.

For MPLS-TP LSPs the same may hold; i.e. if MPLS-TP LSPs
1) are single carrier
2) start/end at metro domain edges or start/end at core domain edges
3) are protected using client CL-SNCG/I protection
then there is no need for LSP TCM.

If we decide that the MPLS-TP is a metro or core domain in a PTN and that
the PTN deploys the EVC as its UNI-to-UNI service/channel layer, then the
MPLS-TP PW provide an EVC link connection and is always a SS-PW. For this
case there is no MPLS-TP PW layer network and there is no need for MPLS-TP
TCM.

The EVC (ETH) layer network with its UNI-to-UNI EVCs there is a EVC TCM
requirement as those EVCs may be multi-carrier EVCs. EVCs may start/end at
UNI-N ports (EVC Type I), or may start/end in the user domain (EVC Type II).

For the case of EVC Type I, the PTN owns all MEG levels (0 to 7). For the
case of EVC Type II, the PTN owns only a subset of MEG levels (e.g. 0 to 4);
the user can deploy all MEG levels (o to 7) inside its own domain, and can
use the top MEG levels (e.g. 5 to 7) in the EVC passing through the PTN.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: vrijdag 17 april 2009 21:25
To: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP
(wasRE:Associatedbidirectional transport path requirements)

Thanks Italo....I understand why you say this.  But I also work closely with
Andy Reid who is the major driving force behind G.800 (and one of the folks
who wrote the initial version of G.805) and it is very clear to me that the
concepts that underpin G.800 are vastly superior to what we understood (as
networking truths) at the time when G.805 was drafted.  But this (ie G.800)
is a more general (and powerful) statement about how networks work and why
we see the networking world as we do, ie 3 modes, etc.  And IMO it shoots
down some sacred networking cows which is why some folks don't like it and
appeal back to the good-old G.805 days.

TCM is a specific issue related to OAM.  And to repeat what I said earlier,
I know of no engineer here in BT (this includes folks like Andy Reid, Alan
McGuire, Ben Niven-Jenkins, me (obviously) etc) who think TCM is a good
idea....quite the opposite in fact.  When we wrote a systems engineering
spec for PBB-TE a while back there was no mention of TCM, and we would hold
the same view for MPLS-TP.....there are far smarter ways to deal with rare
on-demand OAM diagnostics.  So the mere fact that the term TCM appears in
G.805 does not vindicate it's value in any way IMO.

I know you sidestepped my observation on TCM and IP, but if one is seriously
suggesting TCM is such a great idea in IETF then it ought to figure in IP
even before it gets considered for MPLS-TP IMO.....but I strongly suspect it
never will and I think I also know why that would be.

regards, Neil

> To: Harrison,N,Neil,CXM R; [email-masked]; Niven-jenkins,B,Ben,DMF 
> R; [email-masked]; VIGOUREUX MARTIN
> Cc: [email-masked]
> Recommendations based on G.805 (e.g. G.8110.1) will continue to be 
> based on G.805.
> 
> Italo
> 
> > significantly and G.800 (Unified functional architecture of 
> > transport networks) is a more comprehensive embodiment of that 
> > understanding that covers all 3 network modes (based on sound Info 
> > and Systems theory underpinnings).  So G.800 should be the starting 
> > point for any references to the network func architecture for 
> > MPLS-TP and not G.805 IMO.
> > 
> > regards, Neil
> > 
> > > [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH 
> > > A, ATTLABS
> > > I agree with Ben. TCM, with the introduction of MEL as a solution, 
> > > reference to SDH, where trail overhead was overwritten, it created 
> > > a tandem connection. For cell/packet technologies where the OAM 
> > > cells/packets are inserted, it is not clear if this is a tandem 
> > > connection or a new server layer, as both architectural terms are 
> > > used in the standards.
> > > 
> > > Connections may be directly monitored at one end of a connection 
> > > by overwriting some portion of the original trail's overhead 
> > > capacity at the beginning of the connection.
> > > tandem connection, this monitoring method is referred to as tandem 
> > > connection monitoring."
> > > 
> > > Whereas in Y.1711:
> > > given LSP at layer N is to be monitored for some reason (e.g., via 
> > > a CV or P flow say), one way to do this is by creating a new 
> > > server layer LSP (i.e., at layer N + 1) to cover the segment at 
> > > layer N."
> > > 
> > > align on the use. For now, the requirements documents should try 
> > > to avoid it.
> > > 
> > > Deborah
> > > 
> > > particular solution and what we want to do at this stage is 
> > > express the functional requirements and not imply any particular 
> > > solution.
> > >

---

From: "Maarten Vissers" <[email-masked]>
Date: Mon, 20 Apr 2009 15:26:31 +0200

Italo,

You are right.

If you look at the set of network architecture (G.803, G.872, G.8010,
G.8110.1, I.326), equipment (G.806, G.705, G.783, G.798, G.8021, G.8121,
I.732), interface/OAM (G.707, G.709, G.8012, G.8112, I.610, Y.1731),
equipment management (G.7710, G.784, G.874, G.8051, G.8151), protection
(G.841, G.842, G.873.1, G.8031, G.8032, G.8131, I.630) and info model
(G.774, G.874.1, G.8052, G.8152) recommendations then all of those are based
on G.805. 

So far there are no recommendations that have G.800 as basis, as the most
important concept in a transport network (i.e. the "transport entity") was
not present in the first version. G.800 amendment 1 has just introduced this
"transport entity" and also introduced "differentiated connection" as
concepts/definitions into G.800. There is now a misalignment between
definitions and text. Next step is to go through G.800 text and update the
text, including the replacement of e.g. "forwarding relationship" by
"transport entity", replacement of "channel forwarding" by connection,
replacement of "destination forwarding" by "differentiated connection",
addition of some transport network versions of the axioms, e.g. "Axiom 1B
Transport networks are concerned with the **secure and managed** conveyance
of information between senders and receivers **which belong to one user
community** when the senders and receivers are separated geographically."
and more.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of BUSI ITALO
Sent: vrijdag 17 april 2009 20:29
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; VIGOUREUX
MARTIN
Cc: [email-masked]
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP
(wasRE:Associatedbidirectional transport path requirements)

Neil,

G.805 is an in-force Recommendation: G.800 was never intended to replace
G.805.

People who worked on G.800 has always claimed that for connection-oriented
technologies G.800 defaults to G.805.

When Q12/15 consented G.800, it was agreed that existing Recommendations
based on G.805 (e.g. G.8110.1) will continue to be based on G.805.

Italo

> understanding of the physics of networking has improved significantly 
> and G.800 (Unified functional architecture of transport networks) is a 
> more comprehensive embodiment of that understanding that covers all 3 
> network modes (based on sound Info and Systems theory underpinnings).  
> > [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, 
> > ATTLABS
> > has become architecturally confusing. When it was used in reference 
> > connection. For cell/packet technologies where the OAM cells/packets 
> > Connections may be directly monitored at one end of a connection by 
> > overwriting some portion of the original trail's overhead capacity 
> > given LSP at layer N is to be monitored for some reason (e.g., via a 
> > align on the use. For now, the requirements documents should try to 
> > avoid it.
> > 
> > Deborah
> > 
> > particular solution and what we want to do at this stage is express

---

From: "Maarten Vissers" <[email-masked]>
Date: Mon, 20 Apr 2009 16:05:16 +0200

Neil,

> but AIS/FDI in the cl mode?...do me a favour!

Ethernet AIS is indeed a requirement and a necessity. And you will not be
able to understand that as long as you refuse to accept that "cl-mode" is a
forwarding mode within a **transport entity**. G.800 amendment 1 has finally
reintroduced this transport entity into G.800. Besides that, it also
introduced the **differentiated connection**:

[G.800 am1] "A differentiated connection is a transport entity that
transfers information belonging to multiple communications between ports
across a subnetwork. <..> In a differentiated connection message contents
are interpreted to identify (sets of) communications which receive different
treatment.  The sets of communications may be distinguished by the
forwarding identifier or other layer information.  Order is not necessarily
preserved between messages belonging to sets of communications receiving
different treatment.  Sets of communications may be identified for purposes
such as traffic conditioning or preserving communication message order." 

Ethernet VLANs are in terms of G.800 "differentiated connections". Ethernet
AIS provides AIS within the scope of such "differentiated connection". If
you apply this to my proposed PTN layer stack, then the EVC layer topology
will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and P-OTN
VP trails inside metro and core domains interconnecting EVC matrices. When
one of those EVC links is interrupted, e.g. in the core between metro 1 and
metro 4 (see attached slide), then the EVC differentiated connection that is
present on this link will be interrupted. At the EVC switch/bridge node in
metro 4 this interruption is noticed and EVC-AIS is inserted in the
downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4 and
D5.

The EVC-AIS (i.e. Ethernet AIS) frame has a reserved multicast address,
which guarantees that the AIS is broadcast to the endpoints of the EVC.

I believe that it is time for you to adapt your view on co and cl modes and
relate it to the forwarding mode **INSIDE** a transport entity. 

What we know as the internet is essentially an "IP differentiated
connection" with a billion or more ports.
What we know as an IP VPN is essentially an "IP differentiated connection"
with e.g. n ports (n in the range of e.g. 2 to 1000).
What we know as an Ethernet VLAN is essentially an "Ethernet differentiated
connection" with n ports (n in the range of e.g. 2 to 1000).
What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated
connection" with 2 ports.
What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports.

Transport network OAM applies to transport entities, which are (in terms of
G.800 am1) connections and differentiated connections.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

John,  Thanks this is a great platform to explain why OAM for the 3 network
modes needs to be different.  I am getting a wee bit tired of folks trying
to make all 3 network modes look alike (and then, even worse, interwork them
as as peers...esp when not not top-of-stack
networks...I mean how silly can we get?).   I am even more frustrated by
the fact those peddling this FUD only ever seem to consider OAM and forget
all other DP/CP/MP components (esp top-of-stack message/file/stream
application adaptations).  How wrong can this get! 

In the co modes a *connection* is a very specific and *constraining*
construct.....I am assuming here we respect the rules of a connection (ie
single source) though some folks don't even bother to respect this, and this
is despite the fact that we all know what problems multiple-source
constructs can cause (from LDP/PHP....ergo MPLS-TP).

When we have a connection this restricts *all* DP (ie traffic and OAM) to
stay within the bounds of the connection.  Which is fine under defect-free
conditions, but if we have leaking traffic then the constraining nature of
the connection construct is broken.  In a nutshell what this means is that
OAM that is of a request/response nature cannot be trusted in co mode
networks under misconnectivity defects.....indeed, why should a leaking DP
have a symmetric go/return defect behaviour?....very likely it won't.  So
whilst request/response OAM is right for the cl mode it is not right for the
co mode under misconnectivity defect conditions.

More generally the 3 modes are different and not just in OAM
requirements....but AIS/FDI in the cl mode?...do me a favour!...at least
IEEE had the good sense to bin this for Ethernet even though it remains in
Y.1731.  And which is why I often trot-out the rather silly (to have to say
this) observation that if IP (cl mode) could do it all then why have IETF
found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).  The
answer lies in the physics...and G.800 attempts to explain that
physics....G.805 does not.

So, the 3 modes are different...please accept/rejoice in this fact as they
all offer something different/important.  But do not be hoodwinked by those
who peddle a story that that tries to make the OAM of the 3 modes the same. 

regards, Neil 

> OAM functions require a return path, and in the absence of a return 
> path they are disabled.
> 
> charaterized as the elephant in the room.  In the MPLS TP OAM 
> Framework I-D, unicast LSPs are only mentioned three times and return 
> paths not at all.
> 
> Thanks,
> 
> John
> > This requirement does not belong to the first set of requirements 
> > ITU-T is expecting to be met by October.
> > 
> > I think that this requirement needs to be evaluated versus other 
> > more important requirements (e.g. the possibility to work w/o IP 
> > forwarding and the need for OAM to continue to monitor the data 
> > plane also in case of failures affecting the control or management 
> > plane).
> > 
> > I am open to discuss it but not sure this is the right time because 
> > I wish to avoid delaying the first phase of the design solution.
> > 
> > Thanks, Italo
> >

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Apr 2009 16:44:00 +0200

Hi,

I agree with Eric.

Regards, Huub.

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

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

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Apr 2009 16:54:07 +0200

Hi,

I agree with Italo,

It is the behaviour of TCM that is a requirement.
Therefor is should be referred to (e.g. ANSI has T1.105.05 dedicated to 
TCM).
How the behavour is implemented should be in one of the tool drafts.

Regards, Huub.

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

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 20 Apr 2009 16:55:39 +0200

Hi,

I agree with what Italo writes below.

Regards, Huub.

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

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 20 Apr 2009 11:47:26 -0400

I agree with Neil, it is very questionable the value of AIS/FDI in a
packet network- any mode. It can result in a DoS attack by an operator
on themselves so even Y1731 recommends not to block data frames:
"A MEP can decide whether it blocks data frames when it detects dAIS.
The principle requirement
that influences this decision is that data frames ought to be forwarded
as much as possible, without
the possibility of forwarding wrong data frames downstream."
Table I.7-2 shows for AIS, not to block.

And as Y1731 states, AIS can only be used under very constrained
architectures - if required for MPLS-TP, it needs to have the same
guidance as in Y1731, i.e. point-to-point and server/client one-to-one:
"for a point-to-point ETH connection, a MEP has only a single peer MEP.
Therefore, there
is no ambiguity regarding the peer MEP for which it should suppress
alarms when it receives the
ETH-AIS information."
So should only be within one domain - then no need.

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Monday, April 20, 2009 10:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path
requirements

Neil,

> but AIS/FDI in the cl mode?...do me a favour!

Ethernet AIS is indeed a requirement and a necessity. And you will not
be
able to understand that as long as you refuse to accept that "cl-mode"
is a
forwarding mode within a **transport entity**. G.800 amendment 1 has
finally
reintroduced this transport entity into G.800. Besides that, it also
introduced the **differentiated connection**:

[G.800 am1] "A differentiated connection is a transport entity that
transfers information belonging to multiple communications between ports
across a subnetwork. <..> In a differentiated connection message
contents
are interpreted to identify (sets of) communications which receive
different
treatment.  The sets of communications may be distinguished by the
forwarding identifier or other layer information.  Order is not
necessarily
preserved between messages belonging to sets of communications receiving
different treatment.  Sets of communications may be identified for
purposes
such as traffic conditioning or preserving communication message order."

Ethernet VLANs are in terms of G.800 "differentiated connections".
Ethernet
AIS provides AIS within the scope of such "differentiated connection".
If
you apply this to my proposed PTN layer stack, then the EVC layer
topology
will consists of EVC links supported by MPLS-TP, Ethernet, PBB-TE and
P-OTN
VP trails inside metro and core domains interconnecting EVC matrices.
When
one of those EVC links is interrupted, e.g. in the core between metro 1
and
metro 4 (see attached slide), then the EVC differentiated connection
that is
present on this link will be interrupted. At the EVC switch/bridge node
in
metro 4 this interruption is noticed and EVC-AIS is inserted in the
downstream direction to suppress the EVC-LOC alarms at EVC endpoints D4
and
D5.

I believe that it is time for you to adapt your view on co and cl modes
and
relate it to the forwarding mode **INSIDE** a transport entity. 

What we know as the internet is essentially an "IP differentiated
connection" with a billion or more ports.
What we know as an IP VPN is essentially an "IP differentiated
connection"
with e.g. n ports (n in the range of e.g. 2 to 1000).
What we know as an Ethernet VLAN is essentially an "Ethernet
differentiated
connection" with n ports (n in the range of e.g. 2 to 1000).
What we know as a p2p MPLS E-LSP is essentially an "MPLS differentiated
connection" with 2 ports.
What we know as a p2p SDH VC-n is a "SDH VC-n connection" with 2 ports.

Transport network OAM applies to transport entities, which are (in terms
of
G.800 am1) connections and differentiated connections.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

John,  Thanks this is a great platform to explain why OAM for the 3
network
modes needs to be different.  I am getting a wee bit tired of folks
trying
to make all 3 network modes look alike (and then, even worse, interwork
them
as as peers...esp when not not top-of-stack
networks...I mean how silly can we get?).   I am even more frustrated by
the fact those peddling this FUD only ever seem to consider OAM and
forget
all other DP/CP/MP components (esp top-of-stack message/file/stream
application adaptations).  How wrong can this get! 

(ie
single source) though some folks don't even bother to respect this, and
this

When we have a connection this restricts *all* DP (ie traffic and OAM)
to
stay within the bounds of the connection.  Which is fine under
defect-free
conditions, but if we have leaking traffic then the constraining nature
of
the connection construct is broken.  In a nutshell what this means is
that
OAM that is of a request/response nature cannot be trusted in co mode
networks under misconnectivity defects.....indeed, why should a leaking
DP
have a symmetric go/return defect behaviour?....very likely it won't.
So
whilst request/response OAM is right for the cl mode it is not right for
the
co mode under misconnectivity defect conditions.

More generally the 3 modes are different and not just in OAM
requirements....but AIS/FDI in the cl mode?...do me a favour!...at least
IEEE had the good sense to bin this for Ethernet even though it remains
in
Y.1731.  And which is why I often trot-out the rather silly (to have to
say
this) observation that if IP (cl mode) could do it all then why have
IETF
found it necessary to create MPLS (co-ps) and GMPLS (CP for co-cs).  The
answer lies in the physics...and G.800 attempts to explain that
physics....G.805 does not.

So, the 3 modes are different...please accept/rejoice in this fact as
they
all offer something different/important.  But do not be hoodwinked by
those
who peddle a story that that tries to make the OAM of the 3 modes the
same. 

regards, Neil

---

From: "Maarten Vissers" <[email-masked]>
Date: Mon, 20 Apr 2009 18:27:42 +0200

Adrian, 

I agree with you that the term "TCM" and its implied meaning can be replaced
by the underlying specification/requirement. But the concept represented by
the term TCM can not be replaced. From the latest correspondence I believe
that this is now agreed.

Regards,
Maarten

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: donderdag 16 april 2009 14:48
To: Maarten Vissers
Cc: [email-masked]
Subject: Requirement 34 and TCM[Was: Associated bidirectional transport path
requirements]

Maarten,

As to the following...

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Apr 2009 18:04:48 +0100

Hi,

Sounds like an agreement?

We will craft the relevant requirements in terms of the function we want to 
see, and avoid (in these documents) the term "TCM". If what we end up with 
is architectural and functional requirements that identical to TCM that will 
be fine, and if what we end up with is a subtly different that will also be 
fine.

Then, once the requirements are fully stable, we can look at the solution.

Thanks.
I think the authors now have a clear path for updating the documents.

Adrian
----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 20, 2009 5:27 PM
Subject: RE: Requirement 34 and TCM[Was: Associated bidirectional transport 
path requirements]

>> Behalf

---

From: <[email-masked]>
Date: Mon, 20 Apr 2009 18:38:43 +0100

Thanks Deborah...we are only operators/customers...how the heck should
we know what we want ;-)

All I can say here is that folks need to understand the history of how
AIS arose in PDH co-cs networks in the 1st place....binary all 1s (+5V)
was the default death signature of the original TTL logic, it required
no active/concious effort to create it.

Not true in packet-switched networks....AIS generation is an
active/conscious decision here.

But in any case, I stand by what I said about AIS being a meaningless
quantity in cl-ps networks....one needs a *real* long-holding
client/server co mode relationship to even consider it of value (not
some artifically imposed TCM sublayer hierarchy 'just because we can do
it'...we can do lots of things, but its important to distinguish useful
work items from those that just generate costs/problems).

Maarten said "Ethernet AIS is indeed a requirement and a necessity."

Really?

If it's that vital 'a requirement and necessity' then perhaps Maarten
would be kind enough to enlighten us why IEEE decided to remove Ethernet
AIS from 802.1ag?   

And I suppose IETF have also made a major error by not specifying AIS in
IPv4 and IPv6.

regards, Neil

> From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
> Sent: 20 April 2009 16:47
> To: Maarten Vissers; Harrison,N,Neil,CXM R
> Cc: [email-masked]
> > > > > Ben! Can we please try to rewrite this requirement in 
> terms of 
> > > > > behavior?
> > > > >

---

From: [email-masked]
Date: Tue, 21 Apr 2009 08:45:27 +0800

John:
  maybe I don't your meaning. IMO. it is necessary for unidirectional path 
to have a return path.

  regards
  liu

2009-04-20 20:48

收件人
<[email-masked]>
抄送
<[email-masked]>
主题
RE: [mpls-tp] Associated bidirectional transport path requirements

 liu,

Thanks,

John

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 21 Apr 2009 03:20:38 +0200

Ben,

> B) defining a transport profile of MPLS (i.e. MPLS-TP)

The associated bidirectional paths are not required in MPLS-TP (target B).

However, the protocol solution should be applicable to MPLS in general (target A) and therefore associated bidirectional paths should be considered in the protocol design.

Italo

> Sent: Monday, April 20, 2009 1:39 AM
> To: Annamaria Fulignoli; Eric Gray; Lou Berger; BUSI ITALO
> Cc: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> > Eric Gray

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 21 Apr 2009 02:54:38 +0200

Ben,

I am not 100% confortable with your proposal. I would propose the
following changes to your proposal:

1) Remove the term Tandem Connection from the MPLS-TP requirements as it
is redundant (i.e. Not used in that document) and move it to the MPLS-TP
OAM Framework, where it is used extensively

2) Ensure the MPLS-TP OAM requirements express all the necessary
functional requirements around monitoring of end to end paths as well as
parts of end to end paths.
This can be done without referring explicitly to Tandem Connections but
the functional requirements MUST be fully equivalent to the TCM
requirements as per ITU-T definition

3) Keep the TCM solution description, as per JWT agreement, in the
MPLS-TP OAM Framework

4) If a term better than TCM is found, update the MPLS-TP OAM Framework
using this term and clarify in the Rosetta stone that this IETF term is
fully equivalent to the ITU-T TCM term

Italo

> Sent: Saturday, April 18, 2009 3:42 PM
> To: BUSI ITALO; Annamaria Fulignoli; VIGOUREUX MARTIN
> Cc: [email-masked]

---

From: [email-masked]
Date: Tue, 21 Apr 2009 09:59:03 +0800

Deborah:
 maybe what you said is right. but I can't completely agree your opinions. 
IMO. mpls-tp is regard as transport network like SDH/SONET. so it should 
have AIS/FDI fuctions as SDH/SONET.

do you think so.

best regards
liu 

"BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]> 
发件人:  [email-masked]
2009-04-20 23:47

收件人
"Maarten Vissers" <[email-masked]>, <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Apr 2009 10:09:46 +0100

Italo,

Well, you sent me back to look at MPLS-TP_overview-22.ppt

> 3) Keep the TCM solution description, as per JWT agreement, in the

TCM is mentioned in three ways in the slide set, as far as I can see.
1. In the context of describing the requirements
2. In reference to how solutions are achieved in TDM and Ethernet
3. In example solutions

I assume it is the third of these to which you refer.

I would like to remind you that the scope and objectives of the JWT was not 
to design solutions, but to demonstrate that a solution was achievable. 
There was never any commitment that the solution ideas floated in the JWT 
would constrain the solutions work entered into by the IETF with full input 
from all ITU-T participants. Indeed that would have been foolish since the 
JWT was operating in a hurry and was not going into technical details.

If  a technical solution is reached with consensus and matches what the JWT 
considered, that will be fine. But we must not blindly follow the JWT 
solutions work or use any solutions ideas in the JWT report as a 
prerequisite. All technical work must stand on solid technical ground.

Thank you.
Adrian

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 13:30:55 +0100

Liu,
 
If MPLS-TP is going to be taken seriously as a transport network (like SDH/SONET) then the 2 key MUST HAVE requirements are these.
 
1    Provide a transparent client/server relationship...which means:
-    all client bits treated equally
-    client bit ordering preserved
-    no attempt to infer client symbol (ie sequence of client bits) meaning and no attempt to change client symbols
-    the traffic behaviour of client X must not impact the performance experienced by client Y
 
A key corollary of the above is that MPLS-TP must only support proper connections (ie single source constructs)

2   Since MPLS-TP is a transport network it is not a top-of-stack network (ie it does not support directly external message/file/stream applications).  MPLS-TP therefore does not require an E-NNI specification.  A key corollary of this is that MPLS-TP will not have any peer interworking relationship with any other network mode/technology.

Now wrt OAM MPLS-TP is a co-ps mode network.  You could argue this should have FDI/AIS....however, the merit of this is highly questionable.  When I and colleagues discussed whether PBB-TE (also a co-ps mode network) should have FDI/AIS we concluded that on balance it was not a good idea.....and note that initially I was in favour of having AIS, but my colleagues provided strong technical arguments that convinced me otherwise.
 
AIS/FDI is historically linked to the early PDH co-cs mode layer networks that used TTL logic.  When this died it put out a +5V (all 1s) signal by default, ie it required no conscious effort to generate it.....this is key point.  Further, in these networks there is a fairly static/long-holding client server relationship.  Clearly this is not true in the cl-ps mode and it's why IETF have never specified AIS for IP and its why IEEE had the good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO retained it in Y.1731....but I suspect any operator planning to use Ethernet equipment would always look to IEEE stds and not ITU ones).
 
AIS/FDI and the co-ps mode is debatable.  As I noted above, on balance we considered not a good idea for PBB-TE OAM because it requires a conscious effort to generate it (unlike the co-cs mode) so there are likely to be scaling problems and its one more thing to go wrong.
 
You should also have seen me make the point many times in the past that the always-on defect detection/handling OAM needs to be as simple/sparse as possible with as little config as possible because we need super reliability......TCM goes completely against the grain here.  Also note that the OAM required for each of the 3 network modes is not the same, despite what some claim.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 21 April 2009 02:59
	To: BRUNGARD, DEBORAH A, ATTLABS
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	Deborah: 
	 maybe what you said is right. but I can't completely agree your opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it should have AIS/FDI fuctions as SDH/SONET. 
	
	do you think so. 
	
	best regards 
	liu 

2009-04-20 23:47 

收件人

	
	Deborah
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
	Behalf Of Maarten Vissers
	Sent: Monday, April 20, 2009 10:05 AM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path
	requirements
	
	Neil,

	

	

	
	Regards,
	Maarten
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: vrijdag 17 april 2009 22:00
	To: [email-masked]; [email-masked];
	[email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Associated bidirectional transport path
	requirements

	

	
	regards, Neil

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 21 Apr 2009 12:11:55 -0400

Neil,

Please see my question in-line.

Thanks,
Igor

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 21, 2009 8:31 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Liu,

IB>> From what you wrote above (which I completely agree with) one can draw a conclusion that it does not make sense (or not practical to say the least) for a bi-directional MPLS-TP connection (co-routed or not) to have asymmetric (different for each direction) bandwidth allocation. Do you agree with that? More generally, do you think of any reasons why a non-top-of-stack bi-directional transport connection at any layer needs to be bandwidth-wise asymmetrical?

 Thanks,
Igor

regards, Neil

Deborah:

do you think so.

best regards
liu

2009-04-20 23:47

收件人

抄送

[email-masked]

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 21 Apr 2009 09:29:33 -0700

Precisely.   

> Sent: Monday, April 20, 2009 5:45 PM
> To: Drake, John E
> Cc: [email-masked]
>   maybe I don't your meaning. IMO. it is necessary for 
> unidirectional path to have a return path. 
> 
>   regards
>   liu 
> 
> 
> 
> 2009-04-20 20:48 收件人

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 17:50:22 +0100

Thanks Igor....an great question...my comments are in-line:

	From: Igor Bryskin [mailto:[email-masked]] 
	Sent: 21 April 2009 17:12
	To: Harrison,N,Neil,CXM R; [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

	Neil,

	Thanks,

	Igor

	Liu,

	 

	IB>> From what you wrote above (which I completely agree with) 

	NH=> Thanks....and this is very important if we are to avoid generating loads of unnecessary work and creating downstream problems/costs.  I do hope others can also see this.

	  one can draw a conclusion that it does not make sense (or not practical to say the least) for a bi-directional MPLS-TP connection (co-routed or not) to have asymmetric (different for each direction) bandwidth allocation. Do you agree with that?  

	NH=> It's hard to understand why a transport network would require asymmetric BW...though clearly such a construct could be created. 

	But let us pause for a moment and consider what a transport network must do in trying to answer this good question.

	As I noted in 1 above, a critical behaviour of a transport network is to provide a transparent client/server relationship....in essence it is creating client network topology. 

	And although I did not elaborate above why this is so important, once you start to think about what it would be carrying it is likely to be a very large aggregate of (ultimate...not necessarily in the immediate client network) message/file/stream applications....noting that the specific mix of message/file/stream applications can vary epoch by epoch.   Indeed it must carry such an aggregate, because all networks only have purpose if they are ultimately supporting external (to the networks) message/file/stream information transfers...so whilst this transport network is not a top-of-stack network there must a top-of-stack network present (something I think some people fail to fully appreciate). 

	Now whilst the QoS (==delay) requirements of either message, file of stream applications is largely invariant within each application type, the survivability importance can take on any value for any application type.  So transparency (as I defined it above) is therfore not merely some abstract requirement but it is practically essential to have this behaviour to make the transport network operationally tractable (ie simple of transfer function).  Moreover, as a server layer we can make no judgement on the importance of a specific application that may be serveral layer above us anyway.....ergo we *must* have transparency as a critical behaviour in a transport network.

	Of course transparency is a forced behaviour in the co-cs mode (ie no QoS or survivability importance markings here), and this (simplicity) is why the co-cs mode has been so enduringly successful in a transport role, eg PDH and SDH.  When we use a co-ps mode to provide a transport role we must be sure we emulate this transparency behaviour.

	Sorry I have labored this point on transparency a bit, but I hope folks can see why it is rather practically important.  And my point about the large message/file/stream aggregates that must ultimately be carried tends to support a position of symmetric BW IMO.

	 More generally, do you think of any reasons why a non-top-of-stack bi-directional transport connection at any layer needs to be bandwidth-wise asymmetrical?

	NH=> I can't say that I can.

	  regards, Neil

	 Thanks,

	Igor

	 hg

	regards, Neil

		Deborah: 
		
		do you think so. 
		
		best regards 
		liu 

2009-04-20 23:47 

收件人

抄送

[email-masked] 

主题

 

		
		
		Deborah
		
		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] On
		Behalf Of Maarten Vissers
		Sent: Monday, April 20, 2009 10:05 AM
		To: [email-masked]
		Cc: [email-masked]
		Subject: Re: [mpls-tp] Associated bidirectional transport path
		requirements
		
		Neil,

		

		

		
		Regards,
		Maarten
		
		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] 
		Sent: vrijdag 17 april 2009 22:00
		To: [email-masked]; [email-masked];
		[email-masked]; [email-masked]
		Cc: [email-masked]
		Subject: RE: [mpls-tp] Associated bidirectional transport path
		requirements

		

		
		regards, Neil

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 21 Apr 2009 23:46:15 -0700

Hi Adrian,

Completely agreed.

rahul

---

From: guoxinchun <[email-masked]>
Date: Wed, 22 Apr 2009 15:43:53 +0800

Hi Liu, Drake and all, we have discussed this question for a long time, I
have read the mails, I want to say something about it.

First, I think if MPLS-TP is achieved by extending transport capability
based the existent MPLS network (form the mail list we can see this is
expected by many operators), associated bidirectional LSP is necessary.(this
is also the opinion of someone as I remembrance)

Second, I want to say is that I agree unidirectional P2P and P2MP path needs
a return path sometimes, and I think the return path is not MUST to be the
one being associated. However IMO associated bidirectional path may be a
very suitable application for some conditions.

For example, sometimes procedure sends data is form the interface from which
it receives packets from the other. When the interface is unidirectional,
there will be no reverse interface to choose. This condition, if we
associated two unidirectional interfaces, each from a unidirectional path,
it will be very convenient. It looks,feels and behaves like a bidirectional
interface for the upper layer applications.

In addition, associated bidirectional transport path can specify which path
to be associated, that is to say, it can specify the path which with some
specialities such as higher reliability and so on. It is very useful for
some conditions, such as some OAM tools which reply packet is needed. If the
return path is selected randomly, when the random path is unreliable and
fails to transport the reply packet, ingress will mis-consider that the
forward path being checked is unworkable, but in fact the return path
failed. This case, associated bidirectional path is a appropriate
resolution. As the paths associated can be specified as needed, operator can
choose a return path with high reliability to decrease the condition of
mis-judgement.   

For the above reason listed, I think associated bidirectional path is needed
in MPLS-TP and it should be defined in the requirement.

Best regards!
Xinchun Guo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Drake, John E
Sent: Wednesday, April 22, 2009 12:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Precisely.

---

From: [email-masked]
Date: Wed, 22 Apr 2009 16:15:07 +0800

Neil:
  thank you for wasting more time in describling the problems. but I think 
some of what you said is no relations with our problem.for me, maybe 
AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if 
there is no AIS/FDI functions, when there is a defects in a given layer 
network, it can cause multiple alarm events to be raised. it is diffcult 
for operators to locate and diagnose the faults.
 though I completely agree you on  adding new things and functions will 
bring some complexity . but if we have no functions, it is more complex 
and difcult for operators to maintence and administrator the network. so I 
think every new functions and things may have positive and negative 
effects. but we should consider it very much, don't delete some functions 
at random.

best regards
liu

<[email-masked]> 
2009-04-21 20:30

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>
主题
RE: [mpls-tp] Associated bidirectional transport path requirements

Liu,
 
If MPLS-TP is going to be taken seriously as a transport network (like 
SDH/SONET) then the 2 key MUST HAVE requirements are these.
 
1    Provide a transparent client/server relationship...which means:
-    all client bits treated equally
-    client bit ordering preserved
-    no attempt to infer client symbol (ie sequence of client bits) 
meaning and no attempt to change client symbols
-    the traffic behaviour of client X must not impact the performance 
experienced by client Y
 
A key corollary of the above is that MPLS-TP must only support proper 
connections (ie single source constructs)

2   Since MPLS-TP is a transport network it is not a top-of-stack network 
(ie it does not support directly external message/file/stream 
applications).  MPLS-TP therefore does not require an E-NNI specification. 
 A key corollary of this is that MPLS-TP will not have any peer 
interworking relationship with any other network mode/technology.

Now wrt OAM MPLS-TP is a co-ps mode network.  You could argue this should 
have FDI/AIS....however, the merit of this is highly questionable.  When I 
and colleagues discussed whether PBB-TE (also a co-ps mode network) should 
have FDI/AIS we concluded that on balance it was not a good idea.....and 
note that initially I was in favour of having AIS, but my colleagues 
provided strong technical arguments that convinced me otherwise.
 
AIS/FDI is historically linked to the early PDH co-cs mode layer networks 
that used TTL logic.  When this died it put out a +5V (all 1s) signal by 
default, ie it required no conscious effort to generate it.....this is key 
point.  Further, in these networks there is a fairly static/long-holding 
client server relationship.  Clearly this is not true in the cl-ps mode 
and it's why IETF have never specified AIS for IP and its why IEEE had the 
good sense to throw-out AIS in 802.1ag for Ethernet (though ITU have 
unwisely IMO retained it in Y.1731....but I suspect any operator planning 
to use Ethernet equipment would always look to IEEE stds and not ITU 
ones).
 
AIS/FDI and the co-ps mode is debatable.  As I noted above, on balance we 
considered not a good idea for PBB-TE OAM because it requires a conscious 
effort to generate it (unlike the co-cs mode) so there are likely to be 
scaling problems and its one more thing to go wrong.
 
You should also have seen me make the point many times in the past that 
the always-on defect detection/handling OAM needs to be as simple/sparse 
as possible with as little config as possible because we need super 
reliability......TCM goes completely against the grain here.  Also note 
that the OAM required for each of the 3 network modes is not the same, 
despite what some claim.
 
regards, Neil

Of [email-masked]

Deborah: 

do you think so. 

best regards 
liu 

收件人

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil 

--------------------------------------------------------
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: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Wed, 22 Apr 2009 16:22:30 +0800

Feng:

The function of TCM can be provided by nested LSP (Which is the basic function of MPLS-TP), we needn't to define TCM.

Sincerely Yours
2009-04-22  16:20:10

==================== Following is your email=====================
Subject:RE: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements)
Sent：2009-04-20 21:58:18
From:HUANG Feng F
To:[email-masked]; Ben Niven-Jenkins; Busi Italo
CC to:MPLS-TP

>Dear Xueqin,
>     We are discussing requirement of TCM, not for  function and method in details.
>B.R.
>Feng 
>
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Xueqin WEI (Shuetsing WEI)
>Sent: 2009年4月18日 14:52
>To: Ben Niven-Jenkins
>Cc: MPLS-TP
>Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectional transport path requirements)
>

---

From: [email-masked]
Date: Wed, 22 Apr 2009 17:02:29 +0800

I support huanfeng's opinions, here we only disscuss the requirements of 
TCM. how to realize the functions of TCM will be disscussed in the future. 
I wish that xueqin consider it very well.

thank you
liu

"Xueqin WEI (Shuetsing WEI)" <[email-masked]> 
发件人:  [email-masked]
2009-04-22 16:22
请答复 给
[email-masked]

收件人
"HUANG Feng F" <[email-masked]>
抄送
MPLS-TP <[email-masked]>
主题
Re: [mpls-tp] Tandem Connections in MPLS-TP (was 
RE:Associatedbidirectional transport path requirements)

Feng:

The function of TCM can be provided by nested LSP (Which is the basic 
function of MPLS-TP), we needn't to define TCM.

Sincerely Yours

==================== Following is your email=====================
Subject:RE: [mpls-tp] Tandem Connections in MPLS-TP (was 
RE:Associatedbidirectional transport path requirements)
Sent：2009-04-20 21:58:18
From:HUANG Feng F
To:[email-masked]; Ben Niven-Jenkins; Busi Italo
CC to:MPLS-TP

>From: [email-masked] [mailto:[email-masked]] On 
Behalf Of Xueqin WEI (Shuetsing WEI)
>
>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.

---

From: <[email-masked]>
Date: Wed, 22 Apr 2009 11:14:11 +0100

Liu,
 
Allow me to jump in. You are bringing together two things which are separate and for which AIS/FDI is no help. Maintenance operations are concerned with two separate things.
 
1)  Identifying faults in equipment, line plant, and other systems (eg misconfigurations) and fixing them (equipment maintenance).
2)  Identifying the health of end to end connections, especially when they are directly supporting customer services (service maintenance).
 
The problem is *not* about a lack of alarm suppression in the data plane - that information is readily available. If, at an end equipment, I have a good server/section layer and a loss of CC at the client layer, I *know* the fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you think about, if the fault is in the end equipment, it is quite likely that the fault means it cannot report the traffic loss to the management system!)
 
The issue arises because the two sides of maintenance want different things. The fault fixing guys want to locate the fault and don't want any other information. The service maintenance guys want to know whether their customer service is working.
 
This arose in the early days of SONET/SDH, when the operations guys demanded that the equipment did *not* suppress the traffic alarm even when AIS was being received as the service guys want to know about the alarms. The normal practice is for the equipment to report the alarms *including* AIS and then a filter is applied in the management system to suppress alarms to the fault fixing guys. As I'm aware, there are many different techniques applied for the filtering algorithms, especially when you consider multiple concurrent faults in a network, however, the existance of AIS/FDI doesn't add anything to these that's not already known. In fact, I believe simple time-stamp correlation is one of the most powerful and widely used techniques. And if the equipment starts messing up the reporting of loss of CC because it waiting for/persistence checking AIS/FDI, it could end up messing up simple time-stamp correlation! 
 
In practice, it is often not quite a simple as this, as the service guys like to be able to 'localise' the fault. However, under most circumstances, the filter has automatically done this. So localisation you describe is only when the filter hasn't worked for some reason.
 
But the bottom line is, whatever operations process you want to use, AIS/FDI doesn't add anything other than complexity and fault liability to the equipment. Remember AIS goes back to the TDM world where you *have to fill the bit stream with something*.

Andy

Andy Reid 
Chief Network Services Strategist 
BT Innovate 
                                                                                           
Office: +44 (0)1277 322038 
Mobile: +44 (0)7917 025451 
Fax :       +44 (0)1277 324015 
Email:  [email-masked] 

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 22 April 2009 09:15
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	Neil: 
	  thank you for wasting more time in describling the problems. but I think some of what you said is no relations with our problem.for me, maybe AIS/FDI functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there is no AIS/FDI functions, when there is a defects in a given layer network, it can cause multiple alarm events to be raised. it is diffcult  for operators to locate and diagnose the faults. 
	 though I completely agree you on  adding new things and functions will bring some complexity . but if we have no functions, it is more complex and difcult for operators to maintence and administrator the network. so I think every new functions and things may have positive and negative effects. but we should consider it very much, don't delete some functions at random. 

	best regards 
	liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

	Liu, 

	  

	  

	  
	regards, Neil 

	Deborah: 
	
	do you think so. 
	
	best regards 
	liu 

2009-04-20 23:47 

收件人

	

	
	Deborah
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
	Behalf Of Maarten Vissers
	Sent: Monday, April 20, 2009 10:05 AM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path
	requirements
	
	Neil,

	

	

	
	Regards,
	Maarten
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] 
	Sent: vrijdag 17 april 2009 22:00
	To: [email-masked]; [email-masked];
	[email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Associated bidirectional transport path
	requirements

	

	
	regards, Neil

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 22 Apr 2009 13:29:40 +0300

Andy,
I cannot agree more.

Indeed, in the TDM world you had to fill the client bit stream with something predictable AND distinguishable from valid client traffic.
In the packet world, loss of server connectivity means that the client application does not receive any packets, so there is nothing to misinterpret as client traffic.
Hence no need to "fill in" AIS/FDI.

Regards,
    Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 22, 2009 1:14 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Liu,

Andy

Andy Reid

Neil:

best regards
liu

<[email-masked]>

2009-04-21 20:30

收件人

Liu,

regards, Neil

Deborah:

do you think so.

best regards
liu

2009-04-20 23:47

收件人

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: "Maarten Vissers" <[email-masked]>
Date: Wed, 22 Apr 2009 14:45:21 +0200

Neil,
 
I expect that the main requirement for a packet transport network technology
like MPLS-TP is that it is able to support at least the following services:
- E-Line
- E-Tree
- E-LAN
- PDH CES
in a traffic engineered and managed manner.
 
Another main requirement is that it must be able to support those services
in a scalable manner between points anywhere in the world.
 
The E-Line, E-Tree and E-LAN services allow to reorder client frames that
belong to different priorities and to drop client frames that are drop
eligible.
 
The E-Tree and E-LAN services require that client bits are read to deliver
the frames to the appropriate output port or ports of the E-Tree or E-LAN
supporting transport entity/differentiated connection.
 
The packet transport network technology must as such support traffic
engineered transport entities (differentiated connections) with n input
ports (i.e. multi source constructs). This in addition of traffic engineered
transport entities with 1 input port.
 
Regards,
Maarten

  _____  

Sent: dinsdag 21 april 2009 14:31

Liu,

1    Provide a transparent client/server relationship...which means:
-    all client bits treated equally
-    client bit ordering preserved
-    no attempt to infer client symbol (ie sequence of client bits) meaning
and no attempt to change client symbols
-    the traffic behaviour of client X must not impact the performance
experienced by client Y

2   Since MPLS-TP is a transport network it is not a top-of-stack network
(ie it does not support directly external message/file/stream applications).
MPLS-TP therefore does not require an E-NNI specification.  A key corollary
of this is that MPLS-TP will not have any peer interworking relationship
with any other network mode/technology.

AIS/FDI is historically linked to the early PDH co-cs mode layer networks
that used TTL logic.  When this died it put out a +5V (all 1s) signal by
default, ie it required no conscious effort to generate it.....this is key
point.  Further, in these networks there is a fairly static/long-holding
client server relationship.  Clearly this is not true in the cl-ps mode and
it's why IETF have never specified AIS for IP and its why IEEE had the good
sense to throw-out AIS in 802.1ag for Ethernet (though ITU have unwisely IMO
retained it in Y.1731....but I suspect any operator planning to use Ethernet
equipment would always look to IEEE stds and not ITU ones).

You should also have seen me make the point many times in the past that the
always-on defect detection/handling OAM needs to be as simple/sparse as
possible with as little config as possible because we need super
reliability......TCM goes completely against the grain here.  Also note that
the OAM required for each of the 3 network modes is not the same, despite
what some claim.
 
regards, Neil

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil 

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.

---

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Wed, 22 Apr 2009 20:50:40 +0800

Guoman:

Correct: we are discussing requirements of segment monitoring of an End to End LSP.

Sincerely Yours

Development & Planning Department,
Fiberhome Telecommunication Technologies Co.,Ltd.,
No.88 Youkeyuan Road,Hongshan Dist.,Wuhan,Hubei,P.R.China,430074
Tel:    +86 27 87691310
Fax:    +86 27 87694362
Email:  [email-masked]
2009-04-22  20:47:38

==================== Following is your email=====================
Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was RE:Associatedbidirectionaltransport path requirements)
Sent：2009-04-22 17:02:13
From:liu.guoman
To:xqwei
CC to:mpls-tp

---

From: <[email-masked]>
Date: Wed, 22 Apr 2009 14:14:51 +0100

Thanks to both Andy and Sasha here.  Exactly right Sasha....and this is one of the reasons why OAM is not the same for all 3 modes.
 
I am especially delighted to see Andy's comments that amplify why we don't think AIS is a great idea operationally in packet-networks.   
 
regards, Neil 

	From: Alexander Vainshtein [mailto:[email-masked]] 
	Sent: 22 April 2009 11:30
	To: Reid,ABD,Andy,CXM R
	Cc: [email-masked]; [email-masked]; Harrison,N,Neil,CXM R
	Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

	Andy,
	I cannot agree more.

	Regards,
	    Sasha

		Liu,

		 

		 

		 
		Andy

		Andy Reid 

			Neil: 

			best regards 
			liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

			Liu, 

			  

			  

			  
			regards, Neil 

			Deborah: 
			
			do you think so. 
			
			best regards 
			liu 

2009-04-20 23:47 

收件人

			

			
			Deborah
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On
			Behalf Of Maarten Vissers
			Sent: Monday, April 20, 2009 10:05 AM
			To: [email-masked]
			Cc: [email-masked]
			Subject: Re: [mpls-tp] Associated bidirectional transport path
			requirements
			
			Neil,

			

			

			
			Regards,
			Maarten
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] 
			Sent: vrijdag 17 april 2009 22:00
			To: [email-masked]; [email-masked];
			[email-masked]; [email-masked]
			Cc: [email-masked]
			Subject: RE: [mpls-tp] Associated bidirectional transport path
			requirements

			

			
			regards, Neil

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Apr 2009 15:18:13 +0200

Dear all,
We are discussing the requirement of monitoring, managing and protecting the network at different nested levels (i.e. end-to-end LSP, end-to-end PW, segment of LSP, one or more consecutive segments of PWs, links layers).
This is the requirement. Any thing else (like TCM, etc.) is a solution or architectural elements!
So, please, can we conclude and go forward with the requirement draft? 
I think the requirement draft is in a good shape and can move forward. 
It looks like endless looping discussions! We have been there many times and agreed on the correct requirement. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Xueqin WEI (Shuetsing WEI)
Sent: Wednesday, April 22, 2009 3:51 PM
To: liu.guoman
Cc: MPLS-TP
Subject: Re: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectionaltransport path requirements)

Guoman:

Sincerely Yours

---

From: "Maarten Vissers" <[email-masked]>
Date: Wed, 22 Apr 2009 15:22:24 +0200

Deborah,

See inline...

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: maandag 20 april 2009 17:47
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

I agree with Neil, it is very questionable the value of AIS/FDI in a packet
network- any mode. It can result in a DoS attack by an operator on
themselves so even Y1731 recommends not to block data frames:
"A MEP can decide whether it blocks data frames when it detects dAIS.
The principle requirement
that influences this decision is that data frames ought to be forwarded as
much as possible, without the possibility of forwarding wrong data frames
downstream."
Table I.7-2 shows for AIS, not to block.

[mv] I thought that one of the characteristics of a transport network is
that DoS attacks are not possible. AIS/FDI definitely does not result in any
DoS attack.

[mv] With the development of Ethernet OAM two main elements were fixed: 
1) AIS was used solely as an alarm suppression mechanism; i.e. AIS would not
longer be used to trigger for protection switching, nor would it be used as
an input condition for trail signal fail when LOC defect detection is
activated
2) LOC defect detection would not longer block traffic.

[mv] These fixes made sure that there would no longer be an extension of
traffic interruption that could result in the detection of unavailable time
at a downstream point due to a short interruption (e.g. 50 ms). Such could
occur in ATM.

And as Y1731 states, AIS can only be used under very constrained
architectures - if required for MPLS-TP, it needs to have the same guidance
as in Y1731, i.e. point-to-point and server/client one-to-one:
"for a point-to-point ETH connection, a MEP has only a single peer MEP.
Therefore, there
is no ambiguity regarding the peer MEP for which it should suppress alarms
when it receives the ETH-AIS information."
So should only be within one domain - then no need.

[mv] The full text in Y.1731 reads: "For multipoint ETH connectivity, a MEP
cannot determine the specific server (sub) layer entity that has encountered
defect conditions upon receiving a frame with ETH-AIS information. More
importantly, it cannot determine the associated subset of its peer MEPs for
which it should suppress alarms since the received ETH-AIS information does
not contain that information. Therefore, upon reception of a frame with
ETH-AIS information, the MEP will suppress alarms for all peer MEPs whether
there is still connectivity or not.
However, for a point-to-point ETH connection, a MEP has only a single peer
MEP. Therefore, there is no ambiguity regarding the peer MEP for which it
should suppress alarms when it receives the ETH-AIS information. "

[mv] Y.1731 thus states that AIS is used in all VLAN cases, being VLANs with
2 ports (p2p) and VLANs with more then 2 ports (p2mp, rmp, mp2mp). I.e.
there are no constrains in using AIS.

[mv] What the text in Y.1731 describes is that it is possible in a n-port
(n>2) VLAN to have two fault conditions; one is a server layer fault and the
other is a continuity/connectivity fault. If both faults appear in different
branches of the n-port VLAN then a MEP Sink function will detect one or more
LOC defects due to the interruption of one of its link connections, plus it
will detect either one or more LOC defects or MMG defect due to a
configuration fault in one of the matrices within the VLAN. The AIS inserted
due to the server layer fault (link connection interruption) should
essentially only suppress the first set of LOC defects and should not
suppress the second (set of) LOC defect(s/MMG defect. But after a very
detailed analysis (many contributions) it was concluded that selective alarm
suppression was not necessary; i.e. suppression of all alarms (including the
one associated with a connection fault) was sufficient. The main rationale
was that in e.g. a p2p VC12 connection today we can also have two faults,
i.e. a misconnection or open connection and a server layer fault. If the
server layer fault is downstream of the connection fault then also in a
VC-12 connection the server layer fault suppresses awareness of the
connection fault.

Regards,
Maarten

Deborah

-----Original Message-----
Of Maarten Vissers

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Wed, 22 Apr 2009 21:29:41 +0800

Great！I agree.

Sincerely Yours
2009-04-22  21:28:15

==================== Following is your email=====================
Subject:RE: [mpls-tp] Tandem Connections in MPLS-TP (wasRE:Associatedbidirectionaltransport path requirements)
Sent：2009-04-22 21:14:25
From:Sprecher, Nurit (NSN - IL/Hod HaSharon)
To:[email-masked]; liu.guoman
CC to:MPLS-TP

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 22 Apr 2009 09:49:13 -0400

Maarten,

It denies the operator from providing service:
- if configured for no traffic interruption for the customer, while the
customer can claim based on OAM, a lack of service, is a denial of
service for the operator
- if block traffic (which is allowed), depending on the client/server
architecture or a wrong equipment default or a mis-provisioning is also
a denial of service as the traffic may be fine

What you are now supporting is similar to path trace mismatch in the US
standards. Don't block traffic for what may be a possible indication
error. But if an OAM indicator is so questionable on its application,
then it is of no use.

Deborah

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, April 22, 2009 9:22 AM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path
requirements

Deborah,

See inline...

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: maandag 20 april 2009 17:47
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path
requirements

packet
as
much as possible, without the possibility of forwarding wrong data
frames

[mv] I thought that one of the characteristics of a transport network is
that DoS attacks are not possible. AIS/FDI definitely does not result in
any
DoS attack.

[mv] With the development of Ethernet OAM two main elements were fixed: 
1) AIS was used solely as an alarm suppression mechanism; i.e. AIS would
not
longer be used to trigger for protection switching, nor would it be used
as
an input condition for trail signal fail when LOC defect detection is
activated
2) LOC defect detection would not longer block traffic.

[mv] These fixes made sure that there would no longer be an extension of
traffic interruption that could result in the detection of unavailable
time
at a downstream point due to a short interruption (e.g. 50 ms). Such
could
occur in ATM.

guidance
alarms

[mv] The full text in Y.1731 reads: "For multipoint ETH connectivity, a
MEP
cannot determine the specific server (sub) layer entity that has
encountered
defect conditions upon receiving a frame with ETH-AIS information. More
importantly, it cannot determine the associated subset of its peer MEPs
for
which it should suppress alarms since the received ETH-AIS information
does
not contain that information. Therefore, upon reception of a frame with
ETH-AIS information, the MEP will suppress alarms for all peer MEPs
whether
there is still connectivity or not.
However, for a point-to-point ETH connection, a MEP has only a single
peer
MEP. Therefore, there is no ambiguity regarding the peer MEP for which
it
should suppress alarms when it receives the ETH-AIS information. "

[mv] Y.1731 thus states that AIS is used in all VLAN cases, being VLANs
with
2 ports (p2p) and VLANs with more then 2 ports (p2mp, rmp, mp2mp). I.e.
there are no constrains in using AIS.

[mv] What the text in Y.1731 describes is that it is possible in a
n-port
(n>2) VLAN to have two fault conditions; one is a server layer fault and
the
other is a continuity/connectivity fault. If both faults appear in
different
branches of the n-port VLAN then a MEP Sink function will detect one or
more
LOC defects due to the interruption of one of its link connections, plus
it
will detect either one or more LOC defects or MMG defect due to a
configuration fault in one of the matrices within the VLAN. The AIS
inserted
due to the server layer fault (link connection interruption) should
essentially only suppress the first set of LOC defects and should not
suppress the second (set of) LOC defect(s/MMG defect. But after a very
detailed analysis (many contributions) it was concluded that selective
alarm
suppression was not necessary; i.e. suppression of all alarms (including
the
one associated with a connection fault) was sufficient. The main
rationale
was that in e.g. a p2p VC12 connection today we can also have two
faults,
i.e. a misconnection or open connection and a server layer fault. If the
server layer fault is downstream of the connection fault then also in a
VC-12 connection the server layer fault suppresses awareness of the
connection fault.

Regards,
Maarten

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Apr 2009 09:24:30 -0700

Dear Maarten,
I believe that it is not a requirement for MPLS-TP to support any specific
service, including ones you've listed in your message. On the other hand,
support of listed services is a requirement for a client layer that uses
MPLS-TP services.

Regards,
Greg Mirsky

2009/4/22 Maarten Vissers <[email-masked]>

>  Neil,
>
> I expect that the main requirement for a packet transport network
> technology like MPLS-TP is that it is able to support at least the following
> services:
> - E-Line
> - E-Tree
> - E-LAN
> - PDH CES
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* dinsdag 21 april 2009 14:31
> *To:* [email-masked]; [email-masked]
>
> *Cc:* [email-masked]
> *Subject:* Re: [mpls-tp] Associated bidirectional transport path
> requirements
>
>  Liu,
>
> A key corollary of this is that MPLS-TP will not have any peer interworking
> relationship with any other network mode/technology.
>
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of [email-masked]
> *Sent:* 21 April 2009 02:59
> *To:* BRUNGARD, DEBORAH A, ATTLABS
> *Cc:* [email-masked]
> *Subject:* Re: [mpls-tp] Associated bidirectional transport path
> requirements
>
>
> Deborah:
>   *"BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>*
> [email-masked]  主题

---

From: "Maarten Vissers" <[email-masked]>
Date: Wed, 22 Apr 2009 22:50:05 +0200

Dear Greg,
 
Do you mean that there is a layer network above MPLS-TP that will support
these services from UNI-N port to UNI-N port, and that MPLS-TP will support
this service layer network?
 
Regards,
Maarten

  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: woensdag 22 april 2009 18:25
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Dear Maarten,

Regards,
Greg Mirsky

Neil,

 

 
Regards,
Maarten

  _____  

Cc: [email-masked]

Liu,

 

 

 
regards, Neil

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 	

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Apr 2009 14:00:24 -0700

Dear Maarten,
I think you've captured my view pretty accurately. Since MPLS-TP supports
only p2p and p2mp transports it would be responsibility of another layer to
support specific services among UNI-Ns. Interesting thing that E-Tree can
not be directly mapped to p2mp unidirectional MPLS-TP LSP since by MEF's
definition E-Tree is a bidirectional service. (Just a note).

Kind regards,
Greg

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* woensdag 22 april 2009 18:25
> *To:* Maarten Vissers
> *Cc:* [email-masked]; [email-masked]
>
>> the always-on defect detection/handling OAM needs to be as simple/sparse as

---

From: "Maarten Vissers" <[email-masked]>
Date: Thu, 23 Apr 2009 01:23:17 +0200

Dear Greg,
 
Thank you for this confirmation. 
This other layer is that the EVC layer as illustrated in the figure below?
 
  UNI                                                         UNI
--||-------                                           ---------||-----
          |                                           |
  UNI   -------------------------------------------------    UNI
--||----|                 EVC layer                     |-----||-----
        -------------------------------------------------
             | MPLS-TP layer |    |  other layer |
             -----------------    ----------------
 
MEF's E-Tree is a bidirectional rooted-multipoint connection, in which
frames are forwarded on the basis of the value in their DA field. Such
selective forwarding is not supported in an LSP connection. An LSP
connection will as such just support one EVC link connection, i.e. a part of
the EVC between two adjacent EVC switch/bridge functions. Those p2p EVC link
connections simply require non-selective forwarding, something that an LSP
connection can provide.
 
Regards,
Maarten

  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: woensdag 22 april 2009 23:00
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Dear Maarten,

Kind regards,
Greg

Dear Greg,

Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg Mirsky

Neil,

 

 
Regards,
Maarten

  _____  

Cc: [email-masked]

Liu,

 

 

 
regards, Neil

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 	

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 23 Apr 2009 00:58:52 +0100

> have AIS/FDI fuctions as SDH/SONET.

No we must assess the requirements for packet transport networks supporting
the needs of operators today and in the future. We must not blindly recreate
SDH/SONET. If we do so without consideration to how operators' needs and
requirements may have evolved (and continue to evolve in future) we will
have failed IMO and I would severely question the value of the work we will
have produced. If we just recreate SDH/SONET then what is the purpose of the
work an operator would be better off just deploying existing SDH/SONET
equipment.

Ben

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 22 Apr 2009 17:14:34 -0700

Dear Maarten,
I agree with your presentation of layers but only wonder why you've placed
UNIs both as clients of EVC layer as well as its peers. I'd leave UNIs only
as clients of EVC layer. Would you agree?

Regards,
Greg

> *Sent:* woensdag 22 april 2009 23:00
>
> *To:* Maarten Vissers
> *Cc:* [email-masked]
>>> Another main requirement is that it must be able to support those
>>> services in a scalable manner between points anywhere in the world.
>>>
>>> The E-Tree and E-LAN services require that client bits are read to
>>> deliver the frames to the appropriate output port or ports of the E-Tree or
>>> E-LAN supporting transport entity/differentiated connection.
>>>
>>>  maybe what you said is right. but I can't completely agree your
>>> opinions. IMO. mpls-tp is regard as transport network like SDH/SONET. so it
>>> should have AIS/FDI fuctions as SDH/SONET.
>>>
>>> do you think so.
>>>
>>> best regards
>>> liu
>>>
>>>

---

From: [email-masked]
Date: Thu, 23 Apr 2009 09:08:36 +0800

xuanqin：
  I know we are discussing requirements of TCM. but there maybe all kinds 
of methods to realize segment monitoring except nested LSP . why we must 
only select the method of nested LSP? 
 so now it is key problem to whether to need the requirement of TCM 
functions. not discussing the method of realizing the TCM functions. 
do you understand me.

best regards
liu

2009-04-22 20:50
请答复 给
[email-masked]

收件人
"liu.guoman" <[email-masked]>
抄送
"MPLS-TP" <[email-masked]>
主题
Re: Re: [mpls-tp] Tandem Connections in MPLS-TP (was 
RE:Associatedbidirectionaltransport path requirements)

Guoman:

Correct: we are discussing requirements of segment monitoring of an End to 
End LSP.

Sincerely Yours

==================== Following is your email=====================
Subject:Re: [mpls-tp] Tandem Connections in MPLS-TP (was 
RE:Associatedbidirectionaltransport path requirements)
Sent：2009-04-22 17:02:13
From:liu.guoman
To:xqwei
CC to:mpls-tp

>>>monitoring but it does not achieve it using nested PWs or PW levels.
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.
system.

---

From: [email-masked]
Date: Thu, 23 Apr 2009 09:33:46 +0800

I support maarten's opinions completely, here thank MAARTEN for explaining 
it in details.

regards
liu

"Maarten Vissers" <[email-masked]> 
发件人:  [email-masked]
2009-04-22 21:22

收件人
"'BRUNGARD, DEBORAH A, ATTLABS'" <[email-masked]>
抄送
[email-masked]
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

Deborah,

See inline...

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: maandag 20 april 2009 17:47
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path 
requirements

Regards,
Maarten

Deborah

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

Neil,

metro 4 (see attached slide), then the EVC differentiated connection that 

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: [email-masked]
Date: Thu, 23 Apr 2009 14:23:36 +0800

ben:
 I understand your meaning, you still wish to resign and make a more 
reliable and effective, easy to operator and easy to manage packet 
transport network like me. but why not apply this SDH/SONET in the future 
maybe the following cause:
   1 it adopted circuit switching techonogy to bring lower useful of the 
resource than PTN network;
   2 it can't bear all kinds of traffics like PTN networks
it noted that we can't apply SDH/SONET network in the future not because 
it have a complex OAM functions. while more people like to move the 
advantages of  the OAM functions in SDH/SONET to PTN networks. and AIS/FDI 
function is a kind of OAM functions of SDH/SONET . we should use and 
extend the AIS/FDI functions to MPLS-TP ;

best regards
liu

2009-04-23 07:58

收件人
<[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" 
<[email-masked]>
抄送
<[email-masked]>
主题
Re: [mpls-tp] Associated bidirectional transport path requirements

>  maybe what you said is right. but I can't completely agree your 
opinions.
> have AIS/FDI fuctions as SDH/SONET.

No we must assess the requirements for packet transport networks 
supporting
the needs of operators today and in the future. We must not blindly 
recreate
SDH/SONET. If we do so without consideration to how operators' needs and
requirements may have evolved (and continue to evolve in future) we will
have failed IMO and I would severely question the value of the work we 
will
have produced. If we just recreate SDH/SONET then what is the purpose of 
the
work an operator would be better off just deploying existing SDH/SONET
equipment.

Ben

---

From: <[email-masked]>
Date: Thu, 23 Apr 2009 08:03:47 +0100

Liu,
 
Did you not understand the comments that Andy Reid of BT wrote in response to you wrt the efficacy of AIS in packet-switched networks?  I fear you must not have understood these from what you say below.  I have some responses in-line:

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 23 April 2009 07:24
	To: Niven-jenkins,B,Ben,DMF R
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	ben: 
	 I understand your meaning, you still wish to resign and make a more reliable and effective, easy to operator and easy to manage packet transport network like me. but why not apply this SDH/SONET in the future maybe the following cause: 
	   1 it adopted circuit switching techonogy to bring lower useful of the resource than PTN network; 
	   2 it can't bear all kinds of traffics like PTN networks  
	NH=> This is wrong.  The co-cs mode is the best transport solution for any large message/file/stream traffic aggregates for the reasons I have explained before.  Please refer back to my remarks on what transparency means and why this makes the co-cs mode very simple (to operate) in carrying any temporally varying mix of message/file/stream applications in some higher top-of-stack layer network. 
	 
	If we are to substitute a co-ps mode technology for a co-cs mode technology in a transport role we need to pay careful attention to these transparency requirements.  Why?  Because in the co-cs mode one is *forced* to abide by the transparency rules by the physics of how resources are partitioned and labelled here (ie one has no choice here) but this is not true in the co-ps mode.  One can violate the transparency rules in many ways in the co-ps mode, so we have to be conscious of this. 
	 
	The consequence of violating these transparency rules is to incur some degree of added system complexity.....increasing system complexity results in increasing marginal (operational) costs with increasing scale/scope, and thus one generates diseconomies of scale/scope (in any system, not just networking systems....this is a well-known/understood fact for Economists, but it is less well understood by Engineers).
	
	it noted that we can't apply SDH/SONET network in the future not because it have a complex OAM functions. while more people like to move the advantages of  the OAM functions in SDH/SONET to PTN networks. and AIS/FDI function is a kind of OAM functions of SDH/SONET . we should use and extend the AIS/FDI functions to MPLS-TP ;  
	NH=> Well I know its sounds plausible but you are wrong here.  When I originally started looking at what the optimal OAM requirements were for the co-ps mode many years ago I was in favour of applying a FDI/AIS type of function.  However, I have since been convinced by strong technical arguments and real-world operational experience that AIS is not a good idea at all....it has obviously no role in a cl-ps mode network (why do you think IEEE removed it from Ethernet OAM in 802.1ag?  why has IETF never specified it for IPv4/6?) and when you really understand OAM you also realise it is not a good function even in the co-ps mode when we do have proper connections.  AIS only really makes sense in the co-cs mode.
	 
	Please re-read what Andy Reid said in his response to you yesterday on AIS.  
	 
	regards, Neil 
	
	best regards 
	liu 

2009-04-23 07:58 

收件人
<[email-masked]>, "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]> 
抄送
<[email-masked]> 
主题
Re: [mpls-tp] Associated bidirectional transport path requirements	

	

	Ben

---

From: "Maarten Vissers" <[email-masked]>
Date: Thu, 23 Apr 2009 14:35:04 +0200

Dear Greg,
 
The reason I have placed UNIs also as peers of the EVC is because many
operators provide this type of service today. 
E.g. when a packet transport network provides interconnection between an
ISPs service edge router to a group of DSLAMs, then the service edge router
of such ISP is connected to the PTN of the network operator via a rooted-mp
EVC that has an endpoint in the service edge router and in the group of
DSLAMs (case of ATM DSLAMs). With the introduction of VDSL2 and fiber DSLAMs
into the network, the EVC endpoints will be in the home gateways or in the
end-user terminal equipment (STB, PC, VoIP telephone, ...). I have
illustrated these three cases in the attached slides 1 to 3. Slides 4 to 6
illustrate some examples of EVC maintenance entity groups that could be
defined for those three cases. 
 
Another case is carrier-carrier services. Carrier A wants to interconnect
with a number of remote network termination devices which are located behind
the network of a regional carrier B. E.g. 10 NT devices, each connected with
a fast ethernet interface to carrier B network. Carrier A network connects
via 1GE interface to carrier B network. Two scenarios are now possible:
 
1) each fast ethernet interface carries a single VLAN service, which is
carried as an EVC through the network of carrier B towards the interface
with carrier A. At this interface the 10 EVCs are multiplexed onto the 1GE
interface. The EVCs are now commonly owned by carrier A and B, and possibly
by the customer. Carrier B monitors those 10 EVCs via a TCM MEG level.
 
2) each fast ethernet interface carries a number of VLAN services, each
identified by a C-Tag. This group of services is treated as a port based
service in the network of carrier B. This port based service (section VLAN
(EVS)) is treated as EVC in carrier B's network and often identified by
means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 EVSs of the
customers) are multiplex into the 1GE interface and delivered to carrier A's
Virtual UNI-N port. Carrier A's V-UNI-N port treats those 10 EVCs of carrier
B as 10 EVPs, each EVP carrying multiple EVC signals. Each carrier A EVC
signal is traffic conditioned, and gets EVC OAM in the EVC TCM MEP functions
located in this V-UNI-N port card.
- The EVCs in carrier B's network have their endpoints in customer edge
equipment and in the V-UNI-N port of carrier A. For the customer this is an
EVS endpoint, while for the carrier A this is an EVP endpoint. Carrier B's
EVC peers as such with carrier A and customer for this EVC and carrier B
will monitor its EVC via a TCM MEG level.
- The EVCs in carrier A network have their endpoints in the customer network
(e.g. customer edge equipments). Carrier A deploys a TCM MEG level to
monitor this service. 
 
Regards,
Maarten

  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: donderdag 23 april 2009 2:15
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Dear Maarten,

Regards,
Greg

Dear Greg,

  UNI                                                         UNI

Regards,
Maarten

  _____  

To: Maarten Vissers
Cc: [email-masked]

Dear Maarten,

Kind regards,
Greg

Dear Greg,

Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg Mirsky

Neil,

 

 
Regards,
Maarten

  _____  

Cc: [email-masked]

Liu,

 

 

 
regards, Neil

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 	

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 23 Apr 2009 09:29:08 -0700

Ben,

Very well put.

Thanks,

John 

> Sent: Wednesday, April 22, 2009 4:59 PM
> To: [email-masked]; BRUNGARD, DEBORAH A, ATTLABS
> Cc: [email-masked]
> > IMO. mpls-tp is regard as transport network like SDH/SONET. so it 
> No we must assess the requirements for packet transport 
> networks supporting the needs of operators today and in the 
> future. We must not blindly recreate SDH/SONET. If we do so 
> without consideration to how operators' needs and 
> requirements may have evolved (and continue to evolve in 
> future) we will have failed IMO and I would severely question 
> the value of the work we will have produced. If we just 
> recreate SDH/SONET then what is the purpose of the work an 
> operator would be better off just deploying existing 
> SDH/SONET equipment.
> 
> 
> Ben
>

---

From: "David Allan" <[email-masked]>
Date: Thu, 23 Apr 2009 15:14:37 -0400

Hi Maarten:
 
A couple of questions on these charts simply before these examples be considered gospel...from a BBF TR101 perspective....
 
1) You are suggesting broadcast domains on the RMP constructs of up to 80000 end points?
 
2) You do not seem to be extending S-tag, and hence EVP, from DSLAM to Service router... why? This does not seem to correspond to current practice...
 
thanks
Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Thursday, April 23, 2009 8:35 AM
To: 'Greg Mirsky'
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Dear Greg,
 
The reason I have placed UNIs also as peers of the EVC is because many operators provide this type of service today. 
E.g. when a packet transport network provides interconnection between an ISPs service edge router to a group of DSLAMs, then the service edge router of such ISP is connected to the PTN of the network operator via a rooted-mp EVC that has an endpoint in the service edge router and in the group of DSLAMs (case of ATM DSLAMs). With the introduction of VDSL2 and fiber DSLAMs into the network, the EVC endpoints will be in the home gateways or in the end-user terminal equipment (STB, PC, VoIP telephone, ...). I have illustrated these three cases in the attached slides 1 to 3. Slides 4 to 6 illustrate some examples of EVC maintenance entity groups that could be defined for those three cases. 
 
Another case is carrier-carrier services. Carrier A wants to interconnect with a number of remote network termination devices which are located behind the network of a regional carrier B. E.g. 10 NT devices, each connected with a fast ethernet interface to carrier B network. Carrier A network connects via 1GE interface to carrier B network. Two scenarios are now possible:
 
1) each fast ethernet interface carries a single VLAN service, which is carried as an E ging n VC through the network of carrier B towards the interface with carrier A. At this interface the 10 EVCs are multiplexed onto the 1GE interface. The EVCs are now commonly owned by carrier A and B, and possibly by the customer. Carrier B monitors those 10 EVCs via a TCM MEG level.
 
2) each fast ethernet interface carries a number of VLAN services, each identified by a C-Tag. This group of services is treated as a port based service in the network of carrier B. This port based service (section VLAN (EVS)) is treated as EVC in carrier B's network and often identified by means of an S-Tag. These 10 EVCs of carrier B (i.e. 10 EVSs of the customers) are multiplex into the 1GE interface and delivered to carrier A's Virtual UNI-N port. Carrier A's V-UNI-N port treats those 10 EVCs of carrier B as 10 EVPs, each EVP carrying multiple EVC signals. Each carrier A EVC signal is traffic conditioned, and gets EVC OAM in the EVC TCM MEP functions located in this V-UNI-N port card.
- The EVCs in carrier B's network have their endpoints in customer edge equipment and in the V-UNI-N port of carrier A. For the customer this is an EVS endpoint, while for the carrier A this is an EVP endpoint. Carrier B's EVC peers as such with carrier A and customer for this EVC and carrier B will monitor its EVC via a TCM MEG level.
- The EVCs in carrier A network have their endpoints in the customer network (e.g. customer edge equipments). Carrier A deploys a TCM MEG level to monitor this service. 
 
Regards,
Maarten

Dear Maarten,
I agree with your presentation of layers but only wonder why you've placed UNIs both as clients of EVC layer as well as its peers. I'd leave UNIs only as clients of EVC layer. Would you agree?

Regards,
Greg

	Dear Greg,

	  UNI                                                         UNI
	 
	MEF's E-Tree is a bidirectional rooted-multipoint connection, in which frames are forwarded on the basis of the value in their DA field. Such selective forwarding is not supported in an LSP connection. An LSP connection will as such just support one EVC link connection, i.e. a part of the EVC between two adjacent EVC switch/bridge functions. Those p2p EVC link connections simply require non-selective forwarding, something that an LSP connection can provide.
	 
	Regards,
	Maarten

	

	To: Maarten Vissers
	Cc: [email-masked]

	Dear Maarten,
	I think you've captured my view pretty accurately. Since MPLS-TP supports only p2p and p2mp transports it would be responsibility of another layer to support specific services among UNI-Ns. Interesting thing that E-Tree can not be directly mapped to p2mp unidirectional MPLS-TP LSP since by MEF's definition E-Tree is a bidirectional service. (Just a note).
	
	Kind regards,
	Greg

		Dear Greg,
		 
		Do you mean that there is a layer network above MPLS-TP that will support these services from UNI-N port to UNI-N port, and that MPLS-TP will support this service layer network?
		 
		Regards,
		Maarten

		Dear Maarten,
		I believe that it is not a requirement for MPLS-TP to support any specific service, including ones you've listed in your message. On the other hand, support of listed services is a requirement for a client layer that uses MPLS-TP services.
		
		Regards,
		Greg Mirsky

			Neil,
			 
			I expect that the main requirement for a packet transport network technology like MPLS-TP is that it is able to support at least the following services:
			- E-Line
			- E-Tree
			- E-LAN
			- PDH CES
			in a traffic engineered and managed manner.
			 
			Another main requirement is that it must be able to support those services in a scalable manner between points anywhere in the world.
			 
			The E-Line, E-Tree and E-LAN services allow to reorder client frames that belong to different priorities and to drop client frames that are drop eligible.
			 
			The E-Tree and E-LAN services require that client bits are read to deliver the frames to the appropriate output port or ports of the E-Tree or E-LAN supporting transport entity/differentiated connection.
			 
			The packet transport network technology must as such support traffic engineered transport entities (differentiated connections) with n input ports (i.e. multi source constructs). This in addition of traffic engineered transport entities with 1 input port.
			 
			Regards,
			Maarten

			Cc: [email-masked]

			Liu,

			 

			 

			 
			regards, Neil

				Deborah: 
				
				do you think so. 
				
				best regards 
				liu 

2009-04-20 23:47 

收件人

				
				Deborah
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] On
				Behalf Of Maarten Vissers
				Sent: Monday, April 20, 2009 10:05 AM
				To: [email-masked]
				Cc: [email-masked]
				Subject: Re: [mpls-tp] Associated bidirectional transport path
				requirements
				
				Neil,

				

				

				
				Regards,
				Maarten
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] 
				Sent: vrijdag 17 april 2009 22:00
				To: [email-masked]; [email-masked];
				[email-masked]; [email-masked]
				Cc: [email-masked]
				Subject: RE: [mpls-tp] Associated bidirectional transport path
				requirements

				

				
				regards, Neil

---

From: "Maarten Vissers" <[email-masked]>
Date: Thu, 23 Apr 2009 21:41:48 +0200

Andy,
 
> The problem is *not* about a lack of alarm suppression in the data plane -
that information is readily available.
 
I don't believe that this is a correct statement in a multi-operator
transport network, or in transport networks of one operator that have more
then one administrative subdomain (each with its own network management
system). A problem occuring in admin domain A will be unknown in admin
domain B. The loss of continuaity alarms that are activated in admin domain
B due to the fault in admin domain A will appear as primary alarms,
suggesting connectivity problems in admin domain B.
 
> The issue arises because the two sides of maintenance want different
things. The fault fixing
> guys want to locate the fault and don't want any other information. The
service maintenance
> guys want to know whether their customer service is working.
 
This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means
of the additional SSF alarm. The SSF alarm is for the service guys telling
them that the service was interrupted due to a fault in a server layer. AIS
suppresses the LOC alarm in those cases so that the maintenance guys don't
get triggered and start looking for a fault that is outside their area.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: woensdag 22 april 2009 12:14
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Liu,
 
Allow me to jump in. You are bringing together two things which are separate
and for which AIS/FDI is no help. Maintenance operations are concerned with
two separate things.
 
1)  Identifying faults in equipment, line plant, and other systems (eg
misconfigurations) and fixing them (equipment maintenance).
2)  Identifying the health of end to end connections, especially when they
are directly supporting customer services (service maintenance).
 
The problem is *not* about a lack of alarm suppression in the data plane -
that information is readily available. If, at an end equipment, I have a
good server/section layer and a loss of CC at the client layer, I *know* the
fault is elsewhere - I don't need AIS/FDI to tell me. (Indeed, if you think
about, if the fault is in the end equipment, it is quite likely that the
fault means it cannot report the traffic loss to the management system!)
 
The issue arises because the two sides of maintenance want different things.
The fault fixing guys want to locate the fault and don't want any other
information. The service maintenance guys want to know whether their
customer service is working.
 
This arose in the early days of SONET/SDH, when the operations guys demanded
that the equipment did *not* suppress the traffic alarm even when AIS was
being received as the service guys want to know about the alarms. The normal
practice is for the equipment to report the alarms *including* AIS and then
a filter is applied in the management system to suppress alarms to the fault
fixing guys. As I'm aware, there are many different techniques applied for
the filtering algorithms, especially when you consider multiple concurrent
faults in a network, however, the existance of AIS/FDI doesn't add anything
to these that's not already known. In fact, I believe simple time-stamp
correlation is one of the most powerful and widely used techniques. And if
the equipment starts messing up the reporting of loss of CC because it
waiting for/persistence checking AIS/FDI, it could end up messing up simple
time-stamp correlation! 
 
In practice, it is often not quite a simple as this, as the service guys
like to be able to 'localise' the fault. However, under most circumstances,
the filter has automatically done this. So localisation you describe is only
when the filter hasn't worked for some reason.
 
But the bottom line is, whatever operations process you want to use, AIS/FDI
doesn't add anything other than complexity and fault liability to the
equipment. Remember AIS goes back to the TDM world where you *have to fill
the bit stream with something*.

Andy

Andy Reid 

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no. 1800000 
This electronic message contains information from British Telecommunications
plc which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are not
the intended recipient be aware that any disclosure, copying, distribution
or use of the contents of this information is prohibited. If you have
received this electronic message in error, please notify us by telephone or
email (to the numbers or address above) immediately.

Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes.

  _____  

Neil: 
  thank you for wasting more time in describling the problems. but I think
some of what you said is no relations with our problem.for me, maybe AIS/FDI
functions is no sense in cl-ps ,eg. IP. but for CO-PS networks.if there is
no AIS/FDI functions, when there is a defects in a given layer network, it
can cause multiple alarm events to be raised. it is diffcult  for operators
to locate and diagnose the faults. 
 though I completely agree you on  adding new things and functions will
bring some complexity . but if we have no functions, it is more complex and
difcult for operators to maintence and administrator the network. so I think
every new functions and things may have positive and negative effects. but
we should consider it very much, don't delete some functions at random. 

best regards 
liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

抄送
<[email-masked]> 

主题

Liu, 

  

  

  
regards, Neil 

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 23 Apr 2009 23:13:31 +0100

Colleagues,

The current debates appear to be going around in circles and achieving
nothing of value IMO. Two major operators have expressed their opinions and
no operator that I can see has disagreed with those opinions.

I apologise for being direct (and possibly rude) but I am getting tired of
being told by folks who do not represent operators what functionality I need
or should have in my networks.

To put some context on BT's comments in these threads:
I have the largest MPLS network in the UK.
I have one of the largest MPLS networks globally delivering service to 173
countries with over 200 000 customer ports
I have (off the top of my head) at least another 10 MPLS networks in
specific countries covering at least 3 continents delivering dedicated
services to particular market segments.

I have an extremely large SDH network in the UK consisting of over 30 000
switches and supporting in excess of 1 million circuits.
I have an extremely large SDH network globally delivering service in 110
countries.

I would like to think my BT colleagues and I might know a little something
about building large scale networks and the requirements of those networks
and the needs of the customers that I deliver services to.

Can we please stop these circular arguments which are IMO going nowhere and
focus on the task in hand which is defining the requirements (and later
solutions) being asked for by myself, my company and my colleagues in other
operators on this list.

Thanks
Ben

-- 

Ben Niven-Jenkins
IP, Data & Content Architect
Network Infrastructure Architecture, BT
  
E-mail: [email-masked]
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827

British Telecommunications plc. Registered office:  81 Newgate Street London
EC1A 7AJ   Registered in England no:  1800000

---

From: "Maarten Vissers" <[email-masked]>
Date: Fri, 24 Apr 2009 00:48:17 +0200

Ben,

Your company is one of the many operators in the world, and the number of
nodes outside your network is factors larger then the number of nodes inside
your network. My experience is that different operators have different sets
of requirements. Manufacturers have to support the superset of those
requirements. Each operator will then deploy the subset of provided features
that fits its needs (and turn off or don't use the others). Your company for
some years has been asking for less, other operators have been asking for
more. Manufacturers thus build their products with lots of configurability
to support all variations. 

It is my opinion that we should not remove well established features like
AIS, TCM, frame loss counting, delay measurement, loopback, etc before the
majority of operators have agreed that such features are not longer
necessary.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: vrijdag 24 april 2009 0:14
To: [email-masked]
Subject: [mpls-tp] We appear to be going around in circles (Re: Associated
bidirectional transport path requirements)

Colleagues,

To put some context on BT's comments in these threads:
I have the largest MPLS network in the UK.
I have one of the largest MPLS networks globally delivering service to 173
countries with over 200 000 customer ports I have (off the top of my head)
at least another 10 MPLS networks in specific countries covering at least 3
continents delivering dedicated services to particular market segments.

Thanks
Ben

-- 

Ben Niven-Jenkins

On 23/04/2009 07:23, "[email-masked]" <[email-masked]> wrote:

> transport network like me. but why not apply this SDH/SONET in the 
> future maybe the following cause:
>    2 it can't bear all kinds of traffics like PTN networks it noted 
> that we can't apply SDH/SONET network in the future not because it 
> have a complex OAM functions. while more people like to move the 
> advantages of  the OAM functions in SDH/SONET to PTN networks. and 
> AIS/FDI function is a kind of OAM functions of SDH/SONET . we should 
> use and extend the AIS/FDI functions to MPLS-TP ;
> 
> best regards
> liu
> 
> 
> 
> supporting the needs of operators today and in the future. We must not 
> blindly recreate SDH/SONET. If we do so without consideration to how 
> operators' needs and requirements may have evolved (and continue to 
> evolve in future) we will have failed IMO and I would severely 
> question the value of the work we will have produced. If we just 
> recreate SDH/SONET then what is the purpose of the work an operator 
> would be better off just deploying existing SDH/SONET equipment.
> 
> 
> Ben
> 
> 
> 
> 
> 
> mail is solely property of the sender's organization. This mail 
communication to others.
system.

---

From: "Maarten Vissers" <[email-masked]>
Date: Fri, 24 Apr 2009 00:59:02 +0200

Hi Dave,
 
See inline...

  _____  

From: David Allan [mailto:[email-masked]] 
Sent: donderdag 23 april 2009 21:15
To: Maarten Vissers; Greg Mirsky
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Hi Maarten:
 
A couple of questions on these charts simply before these examples be
considered gospel...from a BBF TR101 perspective.... 
 
[mv] Thanks for adding this perspective.. 
 
1) You are suggesting broadcast domains on the RMP constructs of up to 80000
end points? 
 
[mv] yes, this is what I got when I connected 200 subscribers which are
behind 100 VDSL2/Fiber DSLAMs and behind a bridging home gateway with a
service edge router for e.g. VoIP service (each subscriber has 4 phones). It
is a large number, but from a bandwidth perspective (voice) it presumably
could be handled. I expect that in practice there are some other
limitations. Furthermore the subscribers are supported typically by more
then one ISP, so the number of home gateways and/or end terminal devices per
ISP EVC will be lower then this maximum.
 
2) You do not seem to be extending S-tag, and hence EVP, from DSLAM to
Service router... why? This does not seem to correspond to current
practice... 
 
[mv] I was told that this is because the service edge routers could only
handle a single VLAN Tag. Newer service edge nodes will be able to handle
two VLAN Tags (i.e. C and S Tag). Same for DSLAMs. Still the presence of two
VLAN Tags on the interfaces between DSLAM and metro edge node and service
edge and wholesale access nodes will not result in extending the EVP. It
will only allow more then 4k EVCs to be present on those interfaces, which
could be important for business services (which have a dedicated EVC).
 
Regards,
Maarten
 
thanks
Dave

  _____  

Dear Greg,

 
1) each fast ethernet interface carries a single VLAN service, which is
carried as an E ging n VC through the network of carrier B towards the
interface with carrier A. At this interface the 10 EVCs are multiplexed onto
the 1GE interface. The EVCs are now commonly owned by carrier A and B, and
possibly by the customer. Carrier B monitors those 10 EVCs via a TCM MEG
level.

Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg

Dear Greg,

  UNI                                                         UNI

Regards,
Maarten

  _____  

To: Maarten Vissers
Cc: [email-masked]

Dear Maarten,

Kind regards,
Greg

Dear Greg,

Regards,
Maarten

  _____  

Dear Maarten,

Regards,
Greg Mirsky

Neil,

 

 
Regards,
Maarten

  _____  

Cc: [email-masked]

Liu,

 

 

 
regards, Neil

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 	

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 24 Apr 2009 09:43:21 +0300

Maarten,

You have claimed:

<quote>

well established features like AIS, TCM, frame loss counting, delay measurement, loopback, etc

<end quote>

I would be really glad to hear about actual deployment of Ethernet AIS and Y.1731-based frame loss count from the operators.

And, AFAIK,  Ben's call for the operators' show of hands in acknowledgement of deployment of TCM in their networks has not so far, yielded even a single "Yea".

So the question is: What constitutes a well established feature?

My 2c,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Maarten Vissers [[email-masked]]
Sent: Friday, April 24, 2009 1:48 AM
To: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles (Re:     Associated bidirectional transport path requirements)

Ben,

Regards,
Maarten

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

Colleagues,

Thanks
Ben

--

Ben Niven-Jenkins

communication to others.
system.

---

From: <[email-masked]>
Date: Fri, 24 Apr 2009 11:34:12 +0100

Maarten,
 
These points are irrelevant to the points I made. My point is that AIS/FDI gives no information above what is already known - it is only adds complexity and fault liability. Neither of your points change this.
 
Andy

Andy Reid 

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: 23 April 2009 20:42
	To: Reid,ABD,Andy,CXM R
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

	Andy,
	 
	> The problem is *not* about a lack of alarm suppression in the data plane - that information is readily available.
	 
	I don't believe that this is a correct statement in a multi-operator transport network, or in transport networks of one operator that have more then one administrative subdomain (each with its own network management system). A problem occuring in admin domain A will be unknown in admin domain B. The loss of continuaity alarms that are activated in admin domain B due to the fault in admin domain A will appear as primary alarms, suggesting connectivity problems in admin domain B.
	 
	> The issue arises because the two sides of maintenance want different things. The fault fixing
	> guys want to locate the fault and don't want any other information. The service maintenance
	 
	This is addressed in SDH, OTN, Ethernet and T-MPLS recommendations by means of the additional SSF alarm. The SSF alarm is for the service guys telling them that the service was interrupted due to a fault in a server layer. AIS suppresses the LOC alarm in those cases so that the maintenance guys don't get triggered and start looking for a fault that is outside their area.
	 
	Regards,
	Maarten

	Liu,

	 

	 

	 
	Andy

	Andy Reid 

		Neil: 

		best regards 
		liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

		Liu, 

		  

		  

		  
		regards, Neil 

		Deborah: 
		
		do you think so. 
		
		best regards 
		liu 

2009-04-20 23:47 

收件人

		

		
		Deborah
		
		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] On
		Behalf Of Maarten Vissers
		Sent: Monday, April 20, 2009 10:05 AM
		To: [email-masked]
		Cc: [email-masked]
		Subject: Re: [mpls-tp] Associated bidirectional transport path
		requirements
		
		Neil,

		

		

		
		Regards,
		Maarten
		
		-----Original Message-----
		From: [email-masked] [mailto:[email-masked]] 
		Sent: vrijdag 17 april 2009 22:00
		To: [email-masked]; [email-masked];
		[email-masked]; [email-masked]
		Cc: [email-masked]
		Subject: RE: [mpls-tp] Associated bidirectional transport path
		requirements

		

		
		regards, Neil

---

From: <[email-masked]>
Date: Fri, 24 Apr 2009 13:31:14 +0100

I fully agree with Andy on this.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 24 April 2009 11:34
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	Maarten,

	Andy

	Andy Reid 

		Andy,

		 

		Regards,
		Maarten

		Liu,

		 

		 

		 
		Andy

		Andy Reid 

			Neil: 

			best regards 
			liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

			Liu, 

			  

			  

			  
			regards, Neil 

			Deborah: 
			
			do you think so. 
			
			best regards 
			liu 

2009-04-20 23:47 

收件人

			

			
			Deborah
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On
			Behalf Of Maarten Vissers
			Sent: Monday, April 20, 2009 10:05 AM
			To: [email-masked]
			Cc: [email-masked]
			Subject: Re: [mpls-tp] Associated bidirectional transport path
			requirements
			
			Neil,

			

			

			
			Regards,
			Maarten
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] 
			Sent: vrijdag 17 april 2009 22:00
			To: [email-masked]; [email-masked];
			[email-masked]; [email-masked]
			Cc: [email-masked]
			Subject: RE: [mpls-tp] Associated bidirectional transport path
			requirements

			

			
			regards, Neil

---

From: <[email-masked]>
Date: Fri, 24 Apr 2009 13:40:11 +0100

I totally agree Ben.  There is a considerable body of operational experience (esp on OAM requirements) behind the comments you have seen from BT folks.  We are not making these points lightly.

And from the dicussions so far the one thing I would really appreciate the MPLS-TP requirements now capturing is the fact that MPLS-TP (and any type of MPLS or indeed Ethernet) are *not* top-of-stack layer networks and thus they do not need E-NNIs being created for them.  I think I can speak on behalf of all my BT colleagues when I say that we could never support any MPLS-TP standards that mandated E-NNIs in them (and for sure none that advovated peer interworking across E-NNIs with any other non top-of-stack layer network technology like Ethernet).

regards, Neil

> Sent: 23 April 2009 23:14
> To: [email-masked]
> Subject: [mpls-tp] We appear to be going around in circles 
> (Re: Associated bidirectional transport path requirements)
> 
> Colleagues,
> 
> future) we will

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Apr 2009 14:34:53 +0100

Maartin,

> to support all variations.

	Do you see our (BT's) requirements to be very divergent from
those of other operators participating in this effort?  Unless our
requirements are very different, I am confident vendors will build
(or have built) their devices based on our (sensible) requirements.

> majority of operators have agreed that such features are not longer

	Again, that is your opinion, which frankly seems to diverge
from what other operators have expressed. Furthermore, let me  
recommend that
you get out of the habit of telling your customers (or potential ones),
what they require after they have been plainly clear about what they  
want.
Unless you think we don't know what we are talking about. Is this  
perhaps
the case?

	--Tom

---

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Apr 2009 16:48:53 +0200

All,

I spent most of my years in the in the industry on the vendor side, but
for four shiort years I was with an operator.

I'd many opportunities to understand that people working for vendors
very seldom are channeling operator requirements, but rather what
they think the operator requirements should be.

The Lesson learned is that it much better to speak with and listen
to operators than trying to speak for them.

/Loa

Thomas Nadeau wrote:
> from what other operators have expressed. Furthermore, let me recommend 
> that
> what they require after they have been plainly clear about what they want.
> Unless you think we don't know what we are talking about. Is this perhaps
> the case?
> 
>     --Tom
> 
> 
> 
> 
>> Regards,
>> Maarten
>>

-- 

Loa Andersson

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 24 Apr 2009 15:55:03 +0100

Well said.

	--Tom

>>> nodes outside your network is factors larger then the number of  
>>> nodes
>>> inside
>>> your network. My experience is that different operators have  
>>> different
>>> sets
>>> AIS, TCM, frame loss counting, delay measurement, loopback, etc  
>>> before
>>> the
>> recommend
>>> being told by folks who do not represent operators what  
>>> functionality
>>> I need
>>> I have one of the largest MPLS networks globally delivering  
>>> service to
>>> 173
>>> solutions) being asked for by myself, my company and my colleagues  
>>> in
>>> other
>>> operators on this list.
>>>
>>> Thanks
>>> Ben
>>>
>>>
>>> -- 
>>>
>>> Ben Niven-Jenkins
>>> British Telecommunications plc. Registered office:  81 Newgate  
>>> Street
>>> London

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 24 Apr 2009 20:14:46 +0200

Andy,
 
AIS/FDI does give additional information. Let me explain:
 
The need for AIS/FDI is a consequence of the deployment of loss of
continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of
such CCM OAM is to be able to detect a misconfiguration or fault of a
connection function (fabric) in the connection, which interrupts the
forwarding of traffic in the connection. This is a fault condition that can
only be discovered by the layer network in which the connection is
supported. It requires that the organization responsible for the layer
network takes action (i.e. locate the layer's connection function that
includes the fault) to restore the connection.
 
Unfortunately, an interruption of one of the link connections of such
connection (due to a fault in a server layer) will also interrupt the
forwarding of traffic in the connection.
 
As such, loss of CC messages (LOC defect) does not provide sufficient
information to determine if the configuration in the layer's connection
functions along the connection have to be checked and corrected.
 
AIS has been introduced and is used to help differentiate between the two
fault cases.
1) if LOC and AIS are detected, then there is a server layer fault. This
server layer fault is already reported by the server layer MEP detecting
this fault. No action is required, so no alarm to generate. 
2) if LOC is detected and there is no AIS, then there is a layer network
fault (i.e. continuity fault). Fault localization must be started to locate
the misconfigured or failed connection function. Once this faulty connection
function is located, the configuration fault (or hardware fault) can be
corrected, after which the connection is retored.
 
The interruption of the forwarding of traffic in the connection in both
fault cases is however registered as part of performance monitoring. This
performance monitoring information is used to verify the performance against
the SLA for the connection.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 24 april 2009 12:34
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Maarten,
 
These points are irrelevant to the points I made. My point is that AIS/FDI
gives no information above what is already known - it is only adds
complexity and fault liability. Neither of your points change this.
 
Andy

Andy Reid 

  _____  

Andy,

 
things. The fault fixing
service maintenance

Regards,
Maarten

  _____  

Liu,

 

 

 
Andy

Andy Reid 

  _____  

Neil: 

best regards 
liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

抄送
<[email-masked]> 

主题

Liu, 

  

  

  
regards, Neil 

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 24 Apr 2009 18:28:34 -0400

I've been holding off commenting specifically on the need for AIS until I
have a chance to consult with my transport experts. Unfortunately, they were
all at the OIF meeting this past week. However, I can report that when we
previously reviewed the requirements draft, they indicated at that time that
they would prefer MPLS-TP OAM to resemble SONET/SDH OAM due to our embedded
management systems and operator expertise. I hope to be able to report back
soon on further internal discussions.

Cheers,
Andy

2009/4/24 Thomas Nadeau <[email-masked]>

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 24 Apr 2009 15:53:55 -0700

Maarten,

On Fri, 24 Apr 2009, Maarten Vissers wrote:

> of requirements.

Those different operators then must present those different requirements
to the MPLS WG. In the absence of that we have no choice but to work
with the requirements presented by the set of SPs who are currently
involved in formulating the MPLS-TP requirements.

Personally I would very much like to see greater SP involvement in MPLS-TP
requirements effort. And vendors should not proxy for SPs in defining
MPLS-TP requirements.

rahul

 Manufacturers have to support the superset of those

---

From: George Newsome <[email-masked]>
Date: Sat, 25 Apr 2009 17:16:42 -0400

Ben,

In the original "Associated bidirectional transport path requirements"
thread, Maarten wrote:

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

> Maarten Vissers wrote:
> .........
> ..........
> AIS has been introduced and is used to help differentiate between the
> two fault cases.
> ........

As I think Neil reminded us, AIS was not "introduced" at all. It was the
name given to the signal that came out of a PDH equipment when the input
signal failed. It happens because clocks continue to generate output
bits whether there is input or not. Once we had it, we found things to
use it for.

Returning to Ben's "We appear to be going round in circles", it seems to
me that AIS is a cheap, clever, happenstance solution because of the way
that PDH, SDH and OTN work.

The requirements that we need are "solve the problems that AIS solves."
"We need AIS" is specifying a solution to an unstated problem.

The principle thing we used AIS for was to distinguish between equipment
local faults and remote faults. If we received AIS, then the incoming
signal to us was OK and the fault must be remote. The AIS signal acts as
crude OAM for the media; not as OAM for the client. This is clearly an
interaction between the client and its server, and so the requirement is
not a single layer requirement. It is an equipment (and network)
requirement.

The requirements that Ben needs are the things that we accomplished with
AIS that pertain to the mpls-tp layer only. This is true for all the
signals we defined in SDH and OTN OAM.

In the case of AIS, it doesn't seem possible to create a requirement in
the mpls-tp layer only that has an AIS signal as its solution.

Regards,

   George

Ben Niven-Jenkins wrote:
> I apologies for being direct (and possibly rude) but I am getting tired of

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 27 Apr 2009 08:49:34 +0200

Rahul,

> Personally I would very much like to see greater SP involvement in MPLS-TP
requirements effort.

Please read draft-bhh-mpls-tp-oam-y1731. This draft is co-authored by
representatives of DT, FT, KPN, KDDI and CT.

Regards,
Maarten 

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]] 
Sent: zaterdag 25 april 2009 0:54
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles (Re:

Maarten,

On Fri, 24 Apr 2009, Maarten Vissers wrote:

> Ben,
>
> Your company is one of the many operators in the world, and the number 
> of nodes outside your network is factors larger then the number of 
> nodes inside your network. My experience is that different operators 
> have different sets of requirements.

Those different operators then must present those different requirements to
the MPLS WG. In the absence of that we have no choice but to work with the
requirements presented by the set of SPs who are currently involved in
formulating the MPLS-TP requirements.

rahul

> requirements. Each operator will then deploy the subset of provided 
> features that fits its needs (and turn off or don't use the others). 
> Your company for some years has been asking for less, other operators 
> have been asking for more. Manufacturers thus build their products 
> with lots of configurability to support all variations.
>
> It is my opinion that we should not remove well established features 
> like AIS, TCM, frame loss counting, delay measurement, loopback, etc 
> before the majority of operators have agreed that such features are 
> not longer necessary.
>
> Regards,
> Maarten
>
> Behalf Of Ben Niven-Jenkins
> Subject: [mpls-tp] We appear to be going around in circles (Re: 
> nothing of value IMO. Two major operators have expressed their 
> opinions and no operator that I can see has disagreed with those opinions.
>
> I apologise for being direct (and possibly rude) but I am getting 
> tired of being told by folks who do not represent operators what 
> functionality I need or should have in my networks.
>
> I have one of the largest MPLS networks globally delivering service to 
> 173 countries with over 200 000 customer ports I have (off the top of 
> my head) at least another 10 MPLS networks in specific countries 
> covering at least 3 continents delivering dedicated services to particular
market segments.
>
> I have an extremely large SDH network in the UK consisting of over 30 
> 000 switches and supporting in excess of 1 million circuits.
> I have an extremely large SDH network globally delivering service in 
> 110 countries.
>
> I would like to think my BT colleagues and I might know a little 
> something about building large scale networks and the requirements of 
> those networks and the needs of the customers that I deliver services to.
>
> Can we please stop these circular arguments which are IMO going 
> nowhere and focus on the task in hand which is defining the 
> requirements (and later
> solutions) being asked for by myself, my company and my colleagues in 
> other operators on this list.
>
> Thanks
> Ben
>
>
> --
>
> Ben Niven-Jenkins
> > supporting the needs of operators today and in the future. We must 
> > not blindly recreate SDH/SONET. If we do so without consideration to 
> > how operators' needs and requirements may have evolved (and continue 
> > to evolve in future) we will have failed IMO and I would severely 
> > communication is confidential. Recipients named above are obligated 
> > to maintain secrecy and are not permitted to disclose the contents 
> > of this
> communication to others.
> > 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.

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 27 Apr 2009 08:49:34 +0200

Tom,

This AIS discussion has been held in previous technologies as well, e.g.
Ethernet OAM. 
The result was that AIS insertion is optional and that Ethernet equipment
(see G.8021) can be configured to insert Ethernet AIS or to not insert
Ethernet AIS.

> Do you see our (BT's) requirements to be very divergent from those of
other operators participating in this effort?

I see the requirements for OAM that have been expressed in this mpls-tp
discussion by BT representatives to be different from the requirements
expressed by other operator representatives. For example
draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives of DT, FT,
KPN, KDDI and CT. I also see that the OAM requirements defined in MEF (with
input from e.g. AT&T and Verizon) be different from those expressed by BT
representatives. I see that MEF is requesting to support in Y.1731 frame
loss counting for more then one priority level; i.e. an extension of the
existing capability that support frame loss counting for a single priority
(i.e. a case of more OAM, not less OAM).

I see that the operators active in MEF (e.g. AT&T, Verizon, Sprint) have
created and are creating Ethernet UNI, Ethernet E-NNI and Ethernet Virtual
UNI specifications, while representatives of BT state that there can't be
"UNI" or "E-NNI" interfaces associated with packet transport networks, as
those networks are "not top of stack". I see that many operators require
compliance with MEF specifications, including the Ethernet UNI
specification.

I see that e.g. KPN provides a Wholesale Broadband Access (WBA) service via
rooted-multipoint EVCs, which EVCs terminate outside the KPN network (refer
to http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html and
http://www.kpn-wholesale.com/nl/1936-Wholesale_Broadband_Access_Service.html
); i.e. a peer-interconnection case and a potential case for TCM, a case
which according to BT representatives does not exist.

I see that the "message, file, stream" concepts are key to BT's
considerations, while I don't see any of that contributed by other
operators. When I look at the telecom network stack (see attached slide),
then message, file stream are important concepts at Layer 3 (NGN) where
those represent the characteristics of the main services (data, voice,
video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the important
services at Layer 2 (PTN). This raises the question what the scope of
MPLS-TP is for you:
A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which has to support
the IP based Layer 3 Services/Channel layer
B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which has to support
the EVC based Layer 2 Services/Channel layer.

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles (Re:

	Maartin,

> have different sets of requirements. Manufacturers have to support the 
> superset of those requirements. Each operator will then deploy the 
> subset of provided features that fits its needs (and turn off or don't 
> use the others). Your company for some years has been asking for less, 
> other operators have been asking for more. Manufacturers thus build 
> their products with lots of configurability to support all variations.

	Do you see our (BT's) requirements to be very divergent from those
of other operators participating in this effort?  Unless our requirements
are very different, I am confident vendors will build (or have built) their
devices based on our (sensible) requirements.

> before the majority of operators have agreed that such features are 

	Again, that is your opinion, which frankly seems to diverge from
what other operators have expressed. Furthermore, let me recommend that you
get out of the habit of telling your customers (or potential ones), what
they require after they have been plainly clear about what they want.
Unless you think we don't know what we are talking about. Is this perhaps
the case?

	--Tom

> Associated
> my
> head)
> at least another 10 MPLS networks in specific countries covering at 
> least 3 continents delivering dedicated services to particular market 
> segments.
>
>> to maintain secrecy and are not permitted to disclose the contents of 
>> this
> communication to others.
>> the originator of the message. Any views expressed in this message 
>> are those of the individual sender.

---

From: <[email-masked]>
Date: Mon, 27 Apr 2009 11:49:39 +0100

Maarten,
 
It is of course true that adding a boolean input to a logical system increases the number of possible input states. So adding an AIS boolean to CC boolean creates four possible states not just the three you identify below. There are 
 
- good CC, no AIS
- CC fault, AIS present
- good CC, AIS present
- CC fault, no AIS
 
We must ask what practical scenarios could generate each of these input states.
 
Good CC, no AIS
One hopes this is because this is because the service is working properly.
 
CC fault, AIS present
One hopes this is because the service is faulty and one hopes this is because of a fault in a server layer. In fact, the presence of the AIS could be misleading (see below).
 
Good CC, AIS present
This situation could arise because of a misconfiguration of the AIS forwarding label injection table. And there are a number of scenarios which make this quite likely when protection switching occurs. Depending on the exact scope of the forwarding labels, a protection switch may well require the proactive purging of entries from the AIS forwarding label injection table following the protection switch (this could equivalently been seen as the forwarding function proactively dropping the AIS packets).
 
CC fault, no AIS
As you suggest, this could arise from a misconfiguration of a forwarding function. But it could equally arise from a misconfiguration of the AIS forwarding label injection table. In fact, the latter actually seems just as likely and particularly problematic for maintenance. Unlike normal forwarding, any mismatch between the forwarding configuration and the AIS forwarding label injection table will lie dormant and until a server fault arises. Then this generates a false and misunderstood fault condition with maintenance looking for the fault in the wrong place.
 
The first two states can be reliably diagnosed with CC alone. The second two arise from the introduction of the AIS/FDI. However, any possible benefit that might arise is completely masked by the fact that the AIS itself must be configured and there is no reason for this to be more reliable than what it is supposed to be monitoring. Indeed, there seems good reason to think that it will be less reliable.
 
There is no avoiding that AIS in circuit switching is fundamentally different from AIS in packet switching.
 - in circuit switching, you must fill the bit stream with something and the information injected requires no configuration whatsoever.
 - in packet switching, no packets is a perfectly valid condition and the injection of AIS requires individual client connection specific information to be configured.
 
The objective is not to replicate the data plane primitives of SONET/SDH, but the triggers to the operational systems so that the operational systems and processes are the same.
 
The simple CC replicates all the triggers to management systems made by SONET/SDH and gives maximum compatibility. Conversely, the inclusion of data plane AIS requires a whole new area of configuration and generates a whole new set of fault conditions which cannot be localised by SONET/SDH processes. So, ironically, packet AIS is directly opposed to backwards compatibility you claim is the main drive.
 
Andy

Andy Reid 

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: 24 April 2009 19:15
	To: Reid,ABD,Andy,CXM R
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

	Andy,

	The need for AIS/FDI is a consequence of the deployment of loss of continuity checking OAM (e.g. CCM in ethernet, CC in ATM). The objective of such CCM OAM is to be able to detect a misconfiguration or fault of a connection function (fabric) in the connection, which interrupts the forwarding of traffic in the connection. This is a fault condition that can only be discovered by the layer network in which the connection is supported. It requires that the organization responsible for the layer network takes action (i.e. locate the layer's connection function that includes the fault) to restore the connection.
	 
	Unfortunately, an interruption of one of the link connections of such connection (due to a fault in a server layer) will also interrupt the forwarding of traffic in the connection.
	 
	As such, loss of CC messages (LOC defect) does not provide sufficient information to determine if the configuration in the layer's connection functions along the connection have to be checked and corrected.
	 
	AIS has been introduced and is used to help differentiate between the two fault cases.
	1) if LOC and AIS are detected, then there is a server layer fault. This server layer fault is already reported by the server layer MEP detecting this fault. No action is required, so no alarm to generate. 
	2) if LOC is detected and there is no AIS, then there is a layer network fault (i.e. continuity fault). Fault localization must be started to locate the misconfigured or failed connection function. Once this faulty connection function is located, the configuration fault (or hardware fault) can be corrected, after which the connection is retored.
	 
	The interruption of the forwarding of traffic in the connection in both fault cases is however registered as part of performance monitoring. This performance monitoring information is used to verify the performance against the SLA for the connection.
	 
	Regards,
	Maarten

	Maarten,

	Andy

	Andy Reid 

		Andy,

		 

		Regards,
		Maarten

		Liu,

		 

		 

		 
		Andy

		Andy Reid 

			Neil: 

			best regards 
			liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

			Liu, 

			  

			  

			  
			regards, Neil 

			Deborah: 
			
			do you think so. 
			
			best regards 
			liu 

2009-04-20 23:47 

收件人

			

			
			Deborah
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] On
			Behalf Of Maarten Vissers
			Sent: Monday, April 20, 2009 10:05 AM
			To: [email-masked]
			Cc: [email-masked]
			Subject: Re: [mpls-tp] Associated bidirectional transport path
			requirements
			
			Neil,

			

			

			
			Regards,
			Maarten
			
			-----Original Message-----
			From: [email-masked] [mailto:[email-masked]] 
			Sent: vrijdag 17 april 2009 22:00
			To: [email-masked]; [email-masked];
			[email-masked]; [email-masked]
			Cc: [email-masked]
			Subject: RE: [mpls-tp] Associated bidirectional transport path
			requirements

			

			
			regards, Neil

---

From: <[email-masked]>
Date: Mon, 27 Apr 2009 12:45:47 +0100

What a good analysis Andy.  This on its own should be compelling enough to make it clear that we can't simply take FDI/AIS from its PDH/SDH co-cs TDM origins and blindly apply it to packet-switched networks.  But for anyone still not convinced here are some further reasons why AIS (and TCM) make no sense.
 
If one wants to inject an AIS signal into a client from a server one *must* have a permanent binding of server_path<=>client_link_connection.  If you don't have this then there is no one to send the AIS to!  So, in any cases where the client layer network can dynamically change its routing (ie to select different servers for each of its link connections) then it is a pointless exercise attempting to send AIS to the client...as the client has 'moved somewhere else'.
 
Cl-ps networks like IP are obviously like this, and in the limit the client<=>server binding can change for each packet of the IP client, ie new IGP route.  The co-cs PSTN is also like this because it is based on SVCs.  And here if one gets a server layer failure the client calls get cleared down and re-established via other servers than the one that has failed.  So who is the broken server going to send AIS to now?
 
Moving on to consider TCM, what this is doing is creating an artificial client/server sublayer hierarchy.  And as noted above, for a lower TCM level to meaningfully inject AIS towards a higher TCM level the TCM client/server bindings must be permanent.  But this is rather silly because it is *not* the the relationship between TCM levels that it key but the *real traffic relationships between the client and the server*.....in other words we *must* be able to re-route real client traffic around server layer failures (and this includes dynamic restoration, not simply pre-configured protection paths).  
 
Note that the only way one could keep the existing TCM hierarchy valid across failures relative to the client traffic routing would be to create pinch-points at the TCM levels and force the client traffic to always use these.  But now of course one would be reducing the availability potential of the network...so this is not a smart idea at all.
 
The alternative would be to move the TCM levels in accordance to where the real traffic had moved to to effect restoration.  So the dynamic act/deact configuration of TCM levels would have to be defined to track real traffic movements (and it never has been defined).  Note also that in changing the location of the nested TCM levels we have removed their requirement for a permanent client/server binding and so the sending of AIS from lower to higher TCM levels would be pointless....as they too have moved away from the server layer failure just like we need the real traffic to do so (if not clear what I mean here refer back to the PSTN example above...its the same issue).
 
So in addition to Andy's observations of why it is not sensible simply to replicate PDH/SDH AIS behaviour in packet-switched networks we can also see from the above arguments that trying to send AIS between an artificial set of nested TCM levels is also pointless....and this applies to any network mode where the client traffic can move its routing and thus does not have a permanent client<=>server binding relationship.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 27 April 2009 11:50
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	Maarten,

	- good CC, no AIS
	
	- CC fault, AIS present
	- good CC, AIS present
	- CC fault, no AIS

	Good CC, no AIS
	 
	CC fault, AIS present
	 
	Good CC, AIS present
	 
	CC fault, no AIS

	 

	Andy

	Andy Reid 

		Andy,

		 

		 
		 
		Regards,
		Maarten

		Maarten,

		Andy

		Andy Reid 

			Andy,

			 

			Regards,
			Maarten

			Liu,

			 

			 

			 
			Andy

			Andy Reid 

				Neil: 

				best regards 
				liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

				Liu, 

				  

				  

				  
				regards, Neil 

				Deborah: 
				
				do you think so. 
				
				best regards 
				liu 

2009-04-20 23:47 

收件人

				

				
				Deborah
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] On
				Behalf Of Maarten Vissers
				Sent: Monday, April 20, 2009 10:05 AM
				To: [email-masked]
				Cc: [email-masked]
				Subject: Re: [mpls-tp] Associated bidirectional transport path
				requirements
				
				Neil,

				

				

				
				Regards,
				Maarten
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] 
				Sent: vrijdag 17 april 2009 22:00
				To: [email-masked]; [email-masked];
				[email-masked]; [email-masked]
				Cc: [email-masked]
				Subject: RE: [mpls-tp] Associated bidirectional transport path
				requirements

				

				
				regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 27 Apr 2009 14:27:41 +0200

Andy,
 
I have the impression that you do not have the correct understanding of the
SNC protection switching fucntional models and the location and control of
AIS insertion. Your understanding seems not aligned with the specifications
in our equipment and protection swithcing recommendations. See inline...

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 27 april 2009 12:50
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Maarten,
 
It is of course true that adding a boolean input to a logical system
increases the number of possible input states. So adding an AIS boolean to
CC boolean creates four possible states not just the three you identify
below. There are 
 
- good CC, no AIS
- CC fault, AIS present
- good CC, AIS present
- CC fault, no AIS
 
We must ask what practical scenarios could generate each of these input
states.
 
Good CC, no AIS
 
[mv] I don't think that there is only "hope". This condition reflects that
there is no disconnect. 
If every frame/packet arrives correctly is not checked by the reception of
CC and correct MEGID/MEPID. Frame/packet loss is checked by the frame/packet
loss measurement that is embedded in the CCM frames, and can be activated. 
 
CC fault, AIS present
One hopes this is because the service is faulty and one hopes this is
because of a fault in a server layer. In fact, the presence of the AIS could
be misleading (see below). 
 
[mv] With equipment that complies with the equipment standards this
condition doesn't give you just "hope". It gives you "knowledge" that the
discontinutity experienced in the connection is due to a server layer fault.

Good CC, AIS present
This situation could arise because of a misconfiguration of the AIS
forwarding label injection table. And there are a number of scenarios which
make this quite likely when protection switching occurs. Depending on the
exact scope of the forwarding labels, a protection switch may well require
the proactive purging of entries from the AIS forwarding label injection
table following the protection switch (this could equivalently been seen as
the forwarding function proactively dropping the AIS packets). 
 
[mv] I don't think that those scenarios are likely scenarios. Equipment
compliant with ITU-T's equipment recommendations will not have those
scenarios. Only equipment that does not comply with those equipment
recommendations could have such scenarios. Just do not deploy such
equipment.
 
[mv] The AIS insertion in the functional models is performed in the
Adaptation Sink functions. Those Adaptation Sink functions are connected to
the Connection function in which the SNC Protection process is located. The
AIS insertion in an Adaptation sink fucntion continues independent of the
state of the protection switch process in the Connection function; i.e. the
selector in the protection process will only receive frames/packets from
either the working SNC, or the protection SNC (but never from both). 
 
CC fault, no AIS
As you suggest, this could arise from a misconfiguration of a forwarding
function. But it could equally arise from a misconfiguration of the AIS
forwarding label injection table. In fact, the latter actually seems just as
likely and particularly problematic for maintenance. Unlike normal
forwarding, any mismatch between the forwarding configuration and the AIS
forwarding label injection table will lie dormant and until a server fault
arises. Then this generates a false and misunderstood fault condition with
maintenance looking for the fault in the wrong place. 
 
[mv] As indicated in the above comment, equipment compliant with the
equipment and protection switching recommendation will not behave as you
suggest. Only equipment not-compliant with our equipment/protection
switching recommendation may do this, but such equipment should simply not
be deployed.
 
[mv] AIS generation is performed in the adaptation sink function for the set
of active client signals; i.e. for the set of connection/flow points that
are activated on the adaptation sink function (which are represented by the
set of active labels/VIDs/...). There is no "AIS forwarding label injection
table" in any of our equipment recommendations. AIS will be generated for
each client CI output on the set of CPs/FPs on the adaptation sink function
when aAIS consequent action condition is true.

The first two states can be reliably diagnosed with CC alone. The second two
arise from the introduction of the AIS/FDI. However, any possible benefit
that might arise is completely masked by the fact that the AIS itself must
be configured and there is no reason for this to be more reliable than what
it is supposed to be monitoring. Indeed, there seems good reason to think
that it will be less reliable. 
 
[mv] You are turning things upside down... CC is present to detect
continuity and connectivity problems introduced in the layer network's
Connection functions. As such you can not diagnose the second state with CC
alone. With CC alone one of your colleagues will be requested to initiate a
number of Loopback tests to find out which connection function is
misconfigured. This is the wrong action of course, as there is a server
layer fault.
 
[mv] You do not understand the AIS "configuration" aspect. AIS generation
configuration is on the node, not on each individual connection. Networks
that deploy AIS have it active on all their NNIs. 
 
There is no avoiding that AIS in circuit switching is fundamentally
different from AIS in packet switching.
 - in circuit switching, you must fill the bit stream with something and the
information injected requires no configuration whatsoever.
 - in packet switching, no packets is a perfectly valid condition and the
injection of AIS requires individual client connection specific information
to be configured. 
 
[mv] In packet transport networks with connectivity checking no packets is
not a valid condition. 
 
[mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require any
individual client connection specific information. 
 
[mv] ATM VP AIS and ATM VC AIS does not require any individual client (i.e.
VP, VC) connection specific information. 
 
[mv] ETH AIS does not require any individual client connection
identification specification, but it requires reuse of the client MEG Level
information which is also required for the ETH MIP functions on the
interface port.
 
[mv] I.e. AIS insertion does not require individual client connection
specific information. Either no additional information at all is required,
or additional information is required that is shared with other
fucntions/processes in the interface.
 
The objective is not to replicate the data plane primitives of SONET/SDH,
but the triggers to the operational systems so that the operational systems
and processes are the same. 
 
[mv] And that is exactly what we do with support of AIS in packet transport
networks (ATM, Ethernet, T-MPLS => MPLS-TP). 
 
The simple CC replicates all the triggers to management systems made by
SONET/SDH and gives maximum compatibility. Conversely, the inclusion of data
plane AIS requires a whole new area of configuration and generates a whole
new set of fault conditions which cannot be localised by SONET/SDH
processes. So, ironically, packet AIS is directly opposed to backwards
compatibility you claim is the main drive. 
 
[mv] I hope that you now understand that it is the opposite case is that is
present. Simple CC does **not** replicates all triggers... AIS is needed in
addition.
 
Regards,
Maarten
 
Andy

Andy Reid 

  _____  

Andy,

 

 
 
Regards,
Maarten

  _____  

Maarten,

Andy

Andy Reid 

  _____  

Andy,

 
things. The fault fixing
service maintenance

Regards,
Maarten

  _____  

Liu,

 

 

 
Andy

Andy Reid 

  _____  

Neil: 

best regards 
liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

抄送
<[email-masked]> 

主题

Liu, 

  

  

  
regards, Neil 

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: <[email-masked]>
Date: Mon, 27 Apr 2009 13:58:46 +0100

Maarten,
 
Snipped
 
"AIS generation is performed in the adaptation sink function for the set of active client signals; i.e. for the set of connection/flow points that are activated on the adaptation sink function (which are represented by the set of active labels/VIDs/...)."
 
In your words, the adaptation sink function contains a set of label values, one for each client connection. Different words, same thing. This is a list of label values which requires configuration if it is to be used for the injection of AIS and could be configured wrongly. It's the same thing even in your ITU-T speak.
 
Andy

Andy Reid 

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: 27 April 2009 13:28
	To: Reid,ABD,Andy,CXM R
	Cc: [email-masked]
	Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

	Andy,
	 
	I have the impression that you do not have the correct understanding of the SNC protection switching fucntional models and the location and control of AIS insertion. Your understanding seems not aligned with the specifications in our equipment and protection swithcing recommendations. See inline...

	Maarten,

	- good CC, no AIS
	
	- CC fault, AIS present
	- good CC, AIS present
	- CC fault, no AIS

	Good CC, no AIS
	 
	[mv] I don't think that there is only "hope". This condition reflects that there is no disconnect. 
	If every frame/packet arrives correctly is not checked by the reception of CC and correct MEGID/MEPID. Frame/packet loss is checked by the frame/packet loss measurement that is embedded in the CCM frames, and can be activated. 
	 
	CC fault, AIS present
	 
	[mv] With equipment that complies with the equipment standards this condition doesn't give you just "hope". It gives you "knowledge" that the discontinutity experienced in the connection is due to a server layer fault. 
	 
	Good CC, AIS present
	 
	[mv] I don't think that those scenarios are likely scenarios. Equipment compliant with ITU-T's equipment recommendations will not have those scenarios. Only equipment that does not comply with those equipment recommendations could have such scenarios. Just do not deploy such equipment.
	 
	[mv] The AIS insertion in the functional models is performed in the Adaptation Sink functions. Those Adaptation Sink functions are connected to the Connection function in which the SNC Protection process is located. The AIS insertion in an Adaptation sink fucntion continues independent of the state of the protection switch process in the Connection function; i.e. the selector in the protection process will only receive frames/packets from either the working SNC, or the protection SNC (but never from both). 
	 
	CC fault, no AIS
	 
	[mv] As indicated in the above comment, equipment compliant with the equipment and protection switching recommendation will not behave as you suggest. Only equipment not-compliant with our equipment/protection switching recommendation may do this, but such equipment should simply not be deployed.
	 
	[mv] AIS generation is performed in the adaptation sink function for the set of active client signals; i.e. for the set of connection/flow points that are activated on the adaptation sink function (which are represented by the set of active labels/VIDs/...). There is no "AIS forwarding label injection table" in any of our equipment recommendations. AIS will be generated for each client CI output on the set of CPs/FPs on the adaptation sink function when aAIS consequent action condition is true.

	[mv] You are turning things upside down... CC is present to detect continuity and connectivity problems introduced in the layer network's Connection functions. As such you can not diagnose the second state with CC alone. With CC alone one of your colleagues will be requested to initiate a number of Loopback tests to find out which connection function is misconfigured. This is the wrong action of course, as there is a server layer fault.
	 
	[mv] You do not understand the AIS "configuration" aspect. AIS generation configuration is on the node, not on each individual connection. Networks that deploy AIS have it active on all their NNIs. 

	[mv] In packet transport networks with connectivity checking no packets is not a valid condition. 
	 
	[mv] AIS/FDI insertion specified in e.g. T-MPLS OAM does not require any individual client connection specific information. 
	 
	[mv] ATM VP AIS and ATM VC AIS does not require any individual client (i.e. VP, VC) connection specific information. 
	 
	[mv] ETH AIS does not require any individual client connection identification specification, but it requires reuse of the client MEG Level information which is also required for the ETH MIP functions on the interface port.
	 
	[mv] I.e. AIS insertion does not require individual client connection specific information. Either no additional information at all is required, or additional information is required that is shared with other fucntions/processes in the interface.

	[mv] And that is exactly what we do with support of AIS in packet transport networks (ATM, Ethernet, T-MPLS => MPLS-TP). 

	[mv] I hope that you now understand that it is the opposite case is that is present. Simple CC does **not** replicates all triggers... AIS is needed in addition.
	 
	Regards,
	Maarten
	 
	Andy

	Andy Reid 

		Andy,

		 

		 
		 
		Regards,
		Maarten

		Maarten,

		Andy

		Andy Reid 

			Andy,

			 

			Regards,
			Maarten

			Liu,

			 

			 

			 
			Andy

			Andy Reid 

				Neil: 

				best regards 
				liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

				Liu, 

				  

				  

				  
				regards, Neil 

				Deborah: 
				
				do you think so. 
				
				best regards 
				liu 

2009-04-20 23:47 

收件人

				

				
				Deborah
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] On
				Behalf Of Maarten Vissers
				Sent: Monday, April 20, 2009 10:05 AM
				To: [email-masked]
				Cc: [email-masked]
				Subject: Re: [mpls-tp] Associated bidirectional transport path
				requirements
				
				Neil,

				

				

				
				Regards,
				Maarten
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] 
				Sent: vrijdag 17 april 2009 22:00
				To: [email-masked]; [email-masked];
				[email-masked]; [email-masked]
				Cc: [email-masked]
				Subject: RE: [mpls-tp] Associated bidirectional transport path
				requirements

				

				
				regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 27 Apr 2009 15:43:08 +0200

Andy,
 
The configuration of this set of label values in the adaptation function is
locked to the configuration of the set of matrix connections/matrix
forwarding processes.  It is locked to the creation of the "Connection/Flow
Point" that interconnects the Matrix and Adaptation functions. I.e. a sinlge
action which result in configuration of both a Connection function/Matrix
and an Adaptation function/Link End.
 
If there would be any mistake in this configuration, you will notice this
immediately as the CC frames will not reach the MEP Sink functions at the
output ports of the connection (i.e. connection set up is not succesful).
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 27 april 2009 14:59
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Maarten,
 
Snipped
 
"AIS generation is performed in the adaptation sink function for the set of
active client signals; i.e. for the set of connection/flow points that are
activated on the adaptation sink function (which are represented by the set
of active labels/VIDs/...)."
 
In your words, the adaptation sink function contains a set of label values,
one for each client connection. Different words, same thing. This is a list
of label values which requires configuration if it is to be used for the
injection of AIS and could be configured wrongly. It's the same thing even
in your ITU-T speak.
 
Andy

Andy Reid 

  _____  

Andy,

  _____  

Maarten,

- good CC, no AIS

- CC fault, AIS present
- good CC, AIS present
- CC fault, no AIS

Good CC, no AIS

CC fault, AIS present

Good CC, AIS present

 
CC fault, no AIS

 

 

 

 

 
Regards,
Maarten
 
Andy

Andy Reid 

  _____  

Andy,

 

 
 
Regards,
Maarten

  _____  

Maarten,

Andy

Andy Reid 

  _____  

Andy,

 
things. The fault fixing
service maintenance

Regards,
Maarten

  _____  

Liu,

 

 

 
Andy

Andy Reid 

  _____  

Neil: 

best regards 
liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

抄送
<[email-masked]> 

主题

Liu, 

  

  

  
regards, Neil 

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 27 Apr 2009 15:57:38 +0200

Neil,
 
  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: maandag 27 april 2009 13:46
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

What a good analysis Andy.  This on its own should be compelling enough to
make it clear that we can't simply take FDI/AIS from its PDH/SDH co-cs TDM
origins and blindly apply it to packet-switched networks.  But for anyone
still not convinced here are some further reasons why AIS (and TCM) make no
sense. 
 
[mv] As indicated in my response to Andy, his understanding of the AIS
specifications in our equipment and protection switching recommendations is
not correct. It seems that also your understanding of those specifications
is also not correct.
 
If one wants to inject an AIS signal into a client from a server one *must*
have a permanent binding of  s erver_path<=>client_link_connection.   [mv] I
agree that there must be a binding at the time that AIS is generated and
inserted.
 If you don't have this then there is no one to send the AIS to!  So, in any
cases where the client layer network can dynamically change its routing (ie
to select different servers for each of its link connections) then it is a
pointless exercise attempting to send AIS to the client...as the client has
'moved somewhere else'.  [mv] Any client layer network can change its
routing; e.g. as part of restoration. Until such restoration action is
performed it is necessary to generate and insert AIS. Part of such
restoration action is the withdrawal of the binding. At that moment also the
generation of AIS stops. NOTE: in Ethernet networks in which xSTP is
deployed you will find that all n-port connections (VLANs) are restored and
that this restoration process starts immediately after detection of signal
fail condition. That is the reason why ETH AIS generation **within** such
xSTP domain is not performed. 
 
Cl-ps networks like IP are obviously like this, and in the limit the
client<=>server binding can change for each packet of the IP client, ie new
IGP route.  The co-cs PSTN is also like this because it is based on SVCs.
And here if one gets a server layer failure the client calls get cleared
down and re-established via other servers than the one that has failed.  So
who is the broken server going to send AIS to now?  [mv] PSTN: I agree. IP:
For IP we have to look at IP VPNs. Those IP VPNs have fixed bindings between
server and IP VPN. If a interruption of an IP VPN link connection is not
immediately restored, then an IP-AIS may be required when an IP-CCM would be
active. 
 
Moving on to consider TCM, what this is doing is creating an artificial
client/server sublayer hierarchy.  And as noted above, for a lower TCM level
to meaningfully inject AIS towards a higher TCM level the TCM client/server
bindings must be permanent.  [mv] I agree that there must be a binding at
the time that AIS is generated and inserted.
But this is rather silly because it is *not* the the relationship between
TCM levels that it key but the *real traffic relationships between the
client and the server*.....in other words we *must* be able to re-route real
client traffic around server layer failures (and this includes dynamic
restoration, not simply pre-configured protection paths).  [mv] Any client
layer network can change its routing; e.g. as part of restoration.  When
this occurs the TCM end point has to be relocated as well. 
 
[mv] NOTE: TCM endpoints are typically at UNI-N ports and at "E-NNI" ports
("UNI-N":  port with one end connected to customer node and other end
connected to operator node, "E-NNI": NNI with one end connected to operator
A node and other endpoint connected to operator B node). UNI-N ports do not
change; the customer stays connected to those ports. E-NNI ports do not
change; operators A and B stay connected via those ports. If however more
then one E-NNI port is present between networks of two operators, then it is
possible to reroute the client connection via another E-NNI. Often there is
only a single E-NNI agreed for a connection.
 
Note that the only way one could keep the existing TCM hierarchy valid
across failures relative to the client traffic routing would be to create
pinch-points at the TCM levels and force the client traffic to always use
these.  But now of course one would be reducing the availability potential
of the network...so this is not a smart idea at all.  [mv] If one deploys
protection swithcing then the protection edges are indeed carefully selected
pinch-points.... That's why SNC/S (sublayer (i.e. TCM) monitored SNC
protection) works well. If one deploys multi-operator connections, then
there is either one or a small number of gateway nodes via which such
multi-operator connections are crossing admin domain boundaries; i.e.
carefully selected pinch-points.... that is why admin domain monitoring
using TCM works well.
 
The alternative would be to move the TCM levels in accordance to where the
real traffic had moved to to effect restoration.  So the dynamic act/deact
configuration of TCM levels would have to be defined to track real traffic
movements (and it never has been defined).  Note also that in changing the
location of the nested TCM levels we have removed their requirement for a
permanent client/server binding and so the sending of AIS from lower to
higher TCM levels would be pointless....as they too have moved away from the
server layer failure just like we need the real traffic to do so (if not
clear what I mean here refer back to the PSTN example above...its the same
issue).  [mv] When you change the route of a connection through the network,
then you will remove matrix connections in one set of nodes and create new
matrix connections at other nodes. As part of such connection modification
process you need to take care of any other configuration needs associated
with the connection; this may include OAM related configuration at mid
points or protection related configuration.
 
[mv] If you have a network that has 100% of its connections restored (e.g.
PSTN, xSTP domain), there is no reason to generate AIS inside the network.
There is however still a need to generate AIS at the egress ports of the
network, when restoration of the UNI-N to UNI-N connection was not possible.
In a client/server relationship between customer and network, this AIS
insertion can be controlled by the Network Connection (NC) MEP_Sk function
at the UNI-N port. For the case of a peer-interconnection between customer
and nework, this AIS insertion can be controlled by a Tandem Connection (TC)
MEP_Sk function at the UNI-N port.
 
[mv] I do not expect that in packet transport networks we will have 100% of
the connections restored. As such AIS is a necessity. 
 
[mv] The design of AIS in our equipment specifications is such that AIS
insertion stops as soon as the Connection/Flow Point is removed (i.e. when
matrix connection/matrix forwarding process is deleted) from the connection
function by the restoration process. 
 
Regards,
Maarten
 
So in addition to Andy's observations of why it is not sensible simply to
replicate PDH/SDH AIS behaviour in packet-switched networks we can also see
from the above arguments that trying to send AIS between an artificial set
of nested TCM levels is also pointless....and this applies to any network
mode where the client traffic can move its routing and thus does not have a
permanent client<=>server binding relationship.  
 
regards, Neil

  _____  

Maarten,

- good CC, no AIS

- CC fault, AIS present
- good CC, AIS present
- CC fault, no AIS

Good CC, no AIS
 
CC fault, AIS present
 
Good CC, AIS present
 
CC fault, no AIS

 

Andy

Andy Reid 

  _____  

Andy,

 

 
 
Regards,
Maarten

  _____  

Maarten,

Andy

Andy Reid 

  _____  

Andy,

 
things. The fault fixing
service maintenance

Regards,
Maarten

  _____  

Liu,

 

 

 
Andy

Andy Reid 

  _____  

Neil: 

best regards 
liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

抄送
<[email-masked]> 

主题

Liu, 

  

  

  
regards, Neil 

  _____  

Deborah: 

do you think so. 

best regards 
liu 

2009-04-20 23:47 

收件人

抄送
[email-masked] 

主题

Deborah

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

Neil,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 17 april 2009 22:00
To: [email-masked]; [email-masked];

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 27 Apr 2009 15:20:36 +0100

Maarten,

> recommendations could have such scenarios. Just do not deploy such

I have heard this argument of "you just need to buy boxes that are built
properly" before. It's fallacy. Reality is things go wrong. That could be
due to hardware fault (fibre break, circuit board failure etc.), bug
(hardware or software) or operator error.

IME the failure conditions that are hardest to deal with operationally are
bugs & misconfigurations. As Andy shows, in cases of error it is hard to
trust what is configured correctly. Any additional configuration (e.g. AIS
configuration) just increases the likelihood that something has been
misconfigured. It is simple logic.

I also struggle to see your argument of aligning with SDH/SONET primitives
for AIS. If used at all AIS is a northbound function into the management
system is it not? In which case it doesn't matter what primitive the node
(box) uses to trigger that northbound message generation. In SDH/SONET the
AIS primitive was generated automatically and so the node/box could use that
to trigger generation a northbound message. In a packet network an AIS flow
is not generated automatically it needs to be actively inserted. Insertion
of AIS provides no useful information above and beyond that provided by CC,
therefore why can the lack of CC not be used to trigger the generation of
any northbound AIS message if such a message really is required?

What you are proposing AFAICT is definition of additional protocol
primitives (internal to the layer network that are not exposed directly to
the management system) that provide nothing over the existing required
primitives (i.e. CC). At best your proposal provides no value. At worst your
proposal provides confusing and conflicting information to the operator
trying to perform fault analysis.

Ben

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 27 Apr 2009 19:37:38 +0200

Maarten,
 
thanks for your mail. You have just written all I was going to write on this topic.
 
If this is not clear enough, I support your statements and I have nothing more to add.
 
Italo

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
	Sent: Monday, April 27, 2009 2:28 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	Andy,

	Maarten,

	- good CC, no AIS
	
	- CC fault, AIS present
	- good CC, AIS present
	- CC fault, no AIS

	Good CC, no AIS

	CC fault, AIS present

	Good CC, AIS present

	 
	CC fault, no AIS

	 

	 

	 

	 

	 
	Regards,
	Maarten
	 
	Andy

	Andy Reid 

		Andy,

		 

		 
		 
		Regards,
		Maarten

		Maarten,

		Andy

		Andy Reid 

			Andy,

			 

			Regards,
			Maarten

			Liu,

			 

			 

			 
			Andy

			Andy Reid 

				Neil: 

				best regards 
				liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

				Liu, 

				  

				  

				  
				regards, Neil 

				Deborah: 
				
				do you think so. 
				
				best regards 
				liu 

2009-04-20 23:47 

收件人

				

				
				Deborah
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] On
				Behalf Of Maarten Vissers
				Sent: Monday, April 20, 2009 10:05 AM
				To: [email-masked]
				Cc: [email-masked]
				Subject: Re: [mpls-tp] Associated bidirectional transport path
				requirements
				
				Neil,

				

				

				
				Regards,
				Maarten
				
				-----Original Message-----
				From: [email-masked] [mailto:[email-masked]] 
				Sent: vrijdag 17 april 2009 22:00
				To: [email-masked]; [email-masked];
				[email-masked]; [email-masked]
				Cc: [email-masked]
				Subject: RE: [mpls-tp] Associated bidirectional transport path
				requirements

				

				
				regards, Neil

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 27 Apr 2009 19:52:14 +0200

Andy,
 
the key point is that you configure on which existing connections (and not on which labels) you have to generate AIS/FDI. As a consequence you cannot configure AIS generation on a label that is associated with a connection that it is not faulty.
 
If AIS/FDI is enabled by default, than it is your conscious decision to disable it and to live without the feature.
 
Italo

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Monday, April 27, 2009 2:59 PM
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

	Maarten,
	 
	Snipped

	 
	Andy

	Andy Reid 

		Andy,

		Maarten,

		- good CC, no AIS
		
		- CC fault, AIS present
		- good CC, AIS present
		- CC fault, no AIS

		Good CC, no AIS

		CC fault, AIS present

		Good CC, AIS present

		 
		CC fault, no AIS

		 

		 

		 

		 

		 
		Regards,
		Maarten
		 
		Andy

		Andy Reid 

			Andy,

			 

			 
			 
			Regards,
			Maarten

			Maarten,

			Andy

			Andy Reid 

				Andy,

				 

				Regards,
				Maarten

				Liu,

				 

				 

				 
				Andy

				Andy Reid 

					Neil: 

					best regards 
					liu 

<[email-masked]> 

2009-04-21 20:30 

收件人

					Liu, 

					  

					  

					  
					regards, Neil 

					Deborah: 
					
					do you think so. 
					
					best regards 
					liu 

2009-04-20 23:47 

收件人

					

					
					Deborah
					
					-----Original Message-----
					From: [email-masked] [mailto:[email-masked]] On
					Behalf Of Maarten Vissers
					Sent: Monday, April 20, 2009 10:05 AM
					To: [email-masked]
					Cc: [email-masked]
					Subject: Re: [mpls-tp] Associated bidirectional transport path
					requirements
					
					Neil,

					

					

					
					Regards,
					Maarten
					
					-----Original Message-----
					From: [email-masked] [mailto:[email-masked]] 
					Sent: vrijdag 17 april 2009 22:00
					To: [email-masked]; [email-masked];
					[email-masked]; [email-masked]
					Cc: [email-masked]
					Subject: RE: [mpls-tp] Associated bidirectional transport path
					requirements

					

					
					regards, Neil

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Apr 2009 14:20:02 -0400

Dear Maarten,
the draft you've referred to is a proposed solution but not a requirement
that can be satisfied by supporting AIS/FDI.

Regards,
Greg

2009/4/27 Maarten Vissers <[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Apr 2009 14:46:47 -0400

Dear Maarten,
you definitely know but I'd note that MEF formulates requirements for
Carrier Ethernet as a service, i.e. client layer of a transport network, not
requirements for the transport network as server layer. Thus requirements
expressed by SPs at MEF are not applicable or transitive, in my view, to
MPLS-TP, at least not automatically.

Regards,
Greg Mirsky

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Mon, 27 Apr 2009 17:00:22 -0400

Maarten,

I think you have oversimplified the discussion in MEF and in so doing have inaccurately summarized. As Greg says, MEF is oriented towards services (SLA/SLS) and they also recognize that some operators only need simple troubleshooting tools. Considering the on-going discussion in MEF, for the service operators group, it is questionable if Y1731 should be used by MPLS-TP as a baseline as it is considered inadequate. And I don’t see AT&T’s requirements as any different from BT. I think we should follow Adrian’s and Ben’s proposal to define the actual requirements for MPLS-TP before replicating other technologies’ solutions.

And the UNI/ENNI being discussed there is not comparable to your definition.

Deborah

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Monday, April 27, 2009 2:47 PM
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements)

Dear Maarten,
you definitely know but I'd note that MEF formulates requirements for Carrier Ethernet as a service, i.e. client layer of a transport network, not requirements for the transport network as server layer. Thus requirements expressed by SPs at MEF are not applicable or transitive, in my view, to MPLS-TP, at least not automatically. 

Regards,
Greg Mirsky

Tom,

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers

       Maartin,

       --Tom

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 27 Apr 2009 23:14:47 +0200

Hi Andy,

You wrote:

> increases the number of possible input states. So adding an AIS boolean 
> to CC boolean creates four possible states not just the three you 
> identify below. There are
>  
> - good CC, no AIS
> - CC fault, AIS present
> - good CC, AIS present
> - CC fault, no AIS
>  

[hvh] we should also wonder wheter *all* OAM is provisioned correctly

> One hopes this is because this is because the service is working properly.

[hvh] it may be interpreted that CC and AIS are provisioned correctly

> because of a fault in a server layer. In fact, the presence of the AIS 
> could be misleading (see below).

[hvh] one also hopes that CC is correctly (if at all) provisioned, in fact
the absence of CC could be equally misleading
If both CC and AIS are both enabled this state indicates a second
fault: AIS because of a fault in a lower layer, CC absent because of a
fault in this layer.

> forwarding label injection table. And there are a number of scenarios 
> which make this quite likely when protection switching occurs. Depending 
> on the exact scope of the forwarding labels, a protection switch may 
> well require the proactive purging of entries from the AIS forwarding 
> label injection table following the protection switch (this could 
> equivalently been seen as the forwarding function proactively dropping 
> the AIS packets).

[hvh] if the insertion of AIS is a consequent action to a detected defect
*not* configured by management, this state means that in this layer
transport is OK, *and* the Ops does not have to take repair actions.
Insertion of consequent AIS can be enabled/disabled by provisioning.

> forwarding label injection table. In fact, the latter actually seems 
> just as likely and particularly problematic for maintenance. Unlike 
> normal forwarding, any mismatch between the forwarding configuration and 
> the AIS forwarding label injection table will lie dormant and until a 
> server fault arises. Then this generates a false and misunderstood fault 
> condition with maintenance looking for the fault in the wrong place.

[hvh] one hopes that CC generation and AIS injection are enabled

> The first two states can be reliably diagnosed with CC alone. The second 
> two arise from the introduction of the AIS/FDI. 

[hvh] the second and fourth are only reliable if CC is enabled.

> However, any possible 
> benefit that might arise is completely masked by the fact that the AIS 
> itself must be configured and there is no reason for this to be more 
> reliable than what it is supposed to be monitoring. Indeed, there seems 
> good reason to think that it will be less reliable.

[hvh] the enabling of CC generation and the enabling of AIS
insertion make both equally reliable.

>  - in circuit switching, you must fill the bit stream with something and 
> the information injected requires no configuration whatsoever.

[hvh] AIS insertion as consequent action has to be provisioned.

>  - in packet switching, no packets is a perfectly valid condition and 
> the injection of AIS requires individual client connection specific 
> information to be configured.

[hvh] AIS injection is a consequent action, the injection has
to be enabled, a one time action, and not per detected defect

> The objective is not to replicate the data plane primitives of 
> SONET/SDH, but the triggers to the operational systems so that the 
> operational systems and processes are the same.

[hvh] I think that the requirement is that a server layer shall inform
its clients that it has detected a service interuption to ensure that
the clients can inhibit (unnecessary) alarms.

Regards, Huub,
Senior Researcher & Developer

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 27 Apr 2009 14:22:10 -0700

inline

> Sent: Monday, April 27, 2009 2:00 PM
> To: Greg Mirsky; Maarten Vissers
> Cc: [email-masked]
> Subject: Re: [mpls-tp] We appear to be going around in 
> circles(Re:Associated bidirectional transport path requirements)
> 
> Maarten,
> 
>  
> 
> I think you have oversimplified the discussion in MEF and in 
> so doing have inaccurately summarized. As Greg says, MEF is 
> oriented towards services (SLA/SLS) and they also recognize 
> that some operators only need simple troubleshooting tools. 
> Considering the on-going discussion in MEF, for the service 
> operators group, it is questionable if Y1731 should be used 
> by MPLS-TP as a baseline as it is considered inadequate. And 
> I don’t see AT&T’s requirements as any different from BT. I 
> think we should follow Adrian’s and Ben’s proposal to define 
> the actual requirements for MPLS-TP before replicating other 
> technologies’ solutions.

JD:  What a concept.

> [mailto:[email-masked]] On Behalf Of Greg Mirsky
> Subject: Re: [mpls-tp] We appear to be going around in 
> circles (Re:Associated bidirectional transport path requirements)
> 
>  
> 
> Dear Maarten,
> you definitely know but I'd note that MEF formulates 
> requirements for Carrier Ethernet as a service, i.e. client 
> layer of a transport network, not requirements for the 
> transport network as server layer. Thus requirements 
> expressed by SPs at MEF are not applicable or transitive, in 
> my view, to MPLS-TP, at least not automatically. 
> 
> Regards,
> Greg Mirsky
> 
> The result was that AIS insertion is optional and that 
> Ethernet equipment (see G.8021) can be configured to insert 
> Ethernet AIS or to not insert Ethernet AIS.
> 
> 
> I see the requirements for OAM that have been expressed in 
> this mpls-tp discussion by BT representatives to be different 
> from the requirements expressed by other operator 
> representatives. For example
> draft-bhh-mpls-tp-oam-y1731 is co-authored by representatives 
> of DT, FT, KPN, KDDI and CT. I also see that the OAM 
> requirements defined in MEF (with input from e.g. AT&T and 
> Verizon) be different from those expressed by BT 
> representatives. I see that MEF is requesting to support in 
> Y.1731 frame loss counting for more then one priority level; 
> i.e. an extension of the existing capability that support 
> frame loss counting for a single priority (i.e. a case of 
> more OAM, not less OAM).
> 
> I see that the operators active in MEF (e.g. AT&T, Verizon, 
> Sprint) have created and are creating Ethernet UNI, Ethernet 
> E-NNI and Ethernet Virtual UNI specifications, while 
> representatives of BT state that there can't be "UNI" or 
> "E-NNI" interfaces associated with packet transport networks, 
> as those networks are "not top of stack". I see that many 
> operators require compliance with MEF specifications, 
> including the Ethernet UNI specification.
> 
> I see that e.g. KPN provides a Wholesale Broadband Access 
> (WBA) service via rooted-multipoint EVCs, which EVCs 
> terminate outside the KPN network (refer to 
> http://www.kpn-wholesale.com/nl/1672-Broadband_Services.html 
> and 
> ); i.e. a peer-interconnection case and a potential case for 
> TCM, a case which according to BT representatives does not exist.
> 
> I see that the "message, file, stream" concepts are key to 
> BT's considerations, while I don't see any of that 
> contributed by other operators. When I look at the telecom 
> network stack (see attached slide), then message, file stream 
> are important concepts at Layer 3 (NGN) where those represent 
> the characteristics of the main services (data, voice, 
> video), whereas "E-Line, E-Tree, E-LAN, PDH CES, etc" are the 
> important services at Layer 2 (PTN). This raises the question 
> what the scope of MPLS-TP is for you:
> A) MPLS-TP is a Layer 3 Tunnel/Path layer technology which 
> has to support the IP based Layer 3 Services/Channel layer
> B) MPLS-TP is a Layer 2 Tunnel/Path layer technology which 
> has to support the EVC based Layer 2 Services/Channel layer.
> 
> Regards,
> Maarten
> 
> 
>        Do you see our (BT's) requirements to be very 
> divergent from those of other operators participating in this 
> effort?  Unless our requirements are very different, I am 
> confident vendors will build (or have built) their devices 
> based on our (sensible) requirements.
> 
>        Again, that is your opinion, which frankly seems to 
> diverge from what other operators have expressed. 
> Furthermore, let me recommend that you get out of the habit 
> of telling your customers (or potential ones), what they 
> require after they have been plainly clear about what they want.
> Unless you think we don't know what we are talking about. Is 
> this perhaps the case?
> 
>        --Tom
> 
> 
> 
> 
> > Regards,
> > Maarten
> >
> > those networks and the needs of the customers that I 
> deliver services 
> > to.
> >
> > British Telecommunications plc. Registered office:  81 
> Newgate Street 
> > London
> >>   1 it adopted circuit switching techonogy to bring lower 
> useful of 
> >> the resource than PTN network;
> operator

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 27 Apr 2009 23:58:33 +0200

It looks strange to me supporting solutions for something that is not required ...
 
Italo

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
	Sent: Monday, April 27, 2009 8:20 PM
	To: Maarten Vissers
	Cc: [email-masked]
	Subject: Re: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements)

	Dear Maarten,
	the draft you've referred to is a proposed solution but not a requirement that can be satisfied by supporting AIS/FDI.
	
	Regards,
	Greg

		Rahul,

		requirements effort.

		Regards,
		Maarten

		-----Original Message-----
		From: Rahul Aggarwal [mailto:[email-masked]]
		Sent: zaterdag 25 april 2009 0:54
		To: Maarten Vissers
		Cc: 'Ben Niven-Jenkins'; [email-masked]
		Subject: Re: [mpls-tp] We appear to be going around in circles (Re:
		Associated bidirectional transport path requirements)

		Maarten,

		

		rahul
		
		market segments.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 28 Apr 2009 00:01:28 +0100

Maarten,

On 27/04/2009 07:49, "Maarten Vissers" <[email-masked]> wrote:
> representatives.

And your point is? Assumption is the mother of all mess ups. BT was involved
in the development of Y.1731 but inferring from that involvement that BT has
requirements for the entire contents of that document would be erroneous.

Maybe those operators involved in the documents you mention require the
entire contents of those documents, maybe they don't. Unless those operators
choose to express their requirements on the list we won't know and trying to
position involvement in a document as an operator requiring the entire
document is at best misleading IMO.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 08:57:23 +0200

Ben,

> In SDH/SONET the AIS primitive was generated automatically

Your understanding of AIS generation in SDH is not correct. 
AIS generation in SDH is explicitly controlled by the  Consequent Action
process in atomic functions. Furthermore the AIS signal has to be explicitly
generated in SDH equipment. It does not appear automatically. 

E.g. during a cable break you will see that the input port generates a noise
pattern, which results in a arbitrary series of 1 and 0 bits after the
Clock/Data Recovery circuit. Detection of the signal fail condition will now
result in the replacement of this arbitrary 1 and 0 bit stream by the
all-1's AIS bit stream, which creates either MSn frames or VC-n frames in
which all bits are set to 1.

And during a misconnection, the incoming RSn or VC-n signal contains a
non-AIS pattern. The detection of dTIM identifies that the termination sink
function is connected with an unexpected termination source function. This
results in the replacement of the RSn or VC-n signal by the AIS signal.

In OTN a similar AIS control and generation is present in equipment. It
generates either ODUk frames in which all bits are set to 1, or OTUk frames
which contains a PN-11 bit stream, or STM-N frames which contain a PN-11 bit
stream, or 802.3 signals which contain Link Fault or Local Fault code words.

In ATM and Ethernet a similar AIS control and generation is present. But
instead of generating frames in which all bits are set to 1, or frames in
which the bits carry a PN-11 sequence or code words in which the bits carry
a Link/Local Fault indication, in ATM a stream of AIS cells and in Ethernet
a stream of AIS frames is generated. 

> If used at all AIS is a northbound function into the management system
> is it not? In which case it doesn't matter what primitive the node (box)
> uses to trigger that northbound message generation.

Your understanding of AIS usage is not correct. 
AIS is used in the Defect Correlations in the atomic functions. It's main
task is to suppress the fault causes associated with defects which are
detected as a consequence of another primary fault. There is no alternative
primitive available in a transport network that could replace the function
of AIS.

The defect correlation specifications in the ETHx_FT_Sk function are:
cLOC[i] <--	dLOC[i] and (not dAIS) and (not dLCK) and (not CI_SSF) and
(MI_CC_Enable)
cMMG	<--	dMMG
cUNM	<--	dUNM
cUNP	<--	dUNP
cUNL	<--	dUNL
cUNPr <-- 	dUNPr
cRDI	<--	(dRDI[1..n]) and (MI_CC_Enable)
cSSF	<--	CI_SSF or dAIS
cLCK	<--	dLCK and (not dAIS) 
cDEG[1] <--	dDEG[1] and (not dAIS) and (not CI_SSF) and (not (dLOC[1..n]
or dUNL or dMMG or dUNM)) and (MI_CC_Enable)) 

The defect correlation specifications in the Och/OTUk_A_Sk function are:
cLOF	<--	dLOF and (not dAIS) and (not AI_TSF-P)
cLOM	<--	dLOM and (not dLOF) and (not dAIS) and (not AI_TSF-P).

The defect correlation specifications in the ODUkP_TT_Sk are:
cOCI	<--	dOCI and (not CI_SSF)
cLCK	<--	dLCK and (not CI_SSF)
cTIM	<--	dTIM and (not CI_SSF) and (not dAIS) and (not dOCI) and (not
dLCK)
cDEG	<--	dDEG and (not CI_SSF) and (not dAIS) and (not dOCI) and (not
dLCK) and (not (dTIM and (not TIMActDis)))
cBDI	<--	dBDI and (not CI_SSF) and (not dAIS) and (not dOCI) and (not
dLCK) and (not (dTIM and (not TIMActDis)))
cSSF	<--	CI_SSF or dAIS.

> Any additional configuration (e.g. AIS configuration)

There doesn't have to be AIS specific configuration and in most cases there
is no AIS specific configuration.

Regards,
Maarten

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: maandag 27 april 2009 16:21
To: Maarten Vissers; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements

Maarten,

On 27/04/2009 13:27, "Maarten Vissers" <[email-masked]> wrote:
> which make this quite likely when protection switching occurs. 
> Depending on the exact scope of the forwarding labels, a protection 
> switch may well require the proactive purging of entries from the AIS 
> forwarding label injection table following the protection switch (this 
> could equivalently been seen as the forwarding function proactively
dropping the AIS packets).
>  
> [mv] I don't think that those scenarios are likely scenarios. 
> Equipment compliant with ITU-T's equipment recommendations will not 
> have those scenarios. Only equipment that does not comply with those 
> equipment recommendations could have such scenarios. Just do not 
> deploy such equipment.

Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 11:26:13 +0200

Dear Greg,
 
You are right, the draft is a proposed solution. This solution however
implicitly supports the requirements underlying such AIS/FDI. The proposal
is to deploy the well known AIS mechanism to support those requirements;
this proposal and thus the underlying requirement is supported by the
co-authors.
 
For many people, "AIS" expresses both the requirement and the solution. If
we look at Y.1710, Y.1730 and Y.sup4, then we find the following
requirements underlying this AIS/FDI capability:
 
[Y.1710] A defect event in a given layer network should not cause multiple
alarm events to be raised, nor 
cause unnecessary corrective actions to be taken in any higher level
client-layer networks.
 
[Y.1730] A defect event in a given layer network should not cause multiple
alarm events to be raised, nor cause unnecessary corrective actions to be
taken, in any higher-layer level client-layer network. The Ethernet layer
network should support alarm suppression for server layer sourced defects
whose presence have been communicated by forward defect indication means.
Ethernet layer network should support forward defect indication capability
where possible.
 
[Y.sup4] It should be possible to prevent alarms being raised in a client
layer or client sublayer as a
result of a defect in a server layer. 
 
It is possible to use the above text as requirement for the AIS mechanism in
MPLS-TP.
 
Regards,
Maarten
 
  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: maandag 27 april 2009 20:20
To: Maarten Vissers
Cc: Rahul Aggarwal; [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles (Re:
Associatedbidirectional transport path requirements)

Dear Maarten,

Regards,
Greg

Rahul,

requirements effort.

Regards,
Maarten

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]]
Sent: zaterdag 25 april 2009 0:54
To: Maarten Vissers
Cc: 'Ben Niven-Jenkins'; [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles (Re:

Maarten,

rahul

market segments.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 12:47:04 +0200

Dear Greg,
 
If MPLS-TP's role is restricted to the Transport Layer in the MEF layer
stack, then I agree with your observation that requirements expressed by SPs
at MEF are not applicable to MPLS-TP. For such case, the EVC layer will be
the service carrying layer, and MPLS-TP will be one of the technologies that
carries the EVCs.
 
I do not agree with your interpretation that MEF formulates requirements for
carrier ethernet as a client layer of a "transport network". As far as I
understand MEF's specifications, they talk about a "transport layer", not a
"transport network" underneath of the EVC layer. 
 
For me, a transport network includes a service layer as its "top of stack"
layer. The EVC layer is the top-of-stack layer in this carrier ethernet
packet transport network, and the MPLS-TP layer is one of the transport
path/tunnel layers that support the EVC layer.
 
As you notice the difference is just the point where you and I consider the
boundary of a transport network to be. This difference would completely
disappear if we would draw a figure in which we illustrate how e.g. an E-LAN
or E-Line service would be supported. 
 
In my view the transport network boundary is above the EVC layer (i.e. EVC
layer is part of the packet transport network), in analogy to the boundaries
of the SDH transport network (above the LO VC layer), OTN transport network
(above LO ODU layer) and ATM transport network (above ATM VC layer).
 
In my view you have comparable roles of the following layers:
 
- service/channel layer (UNI-N to UNI-N connectivity): 
SDH LO VC - OTN LO ODU - ATM VC - EVC
 
- tunnel/path layer (domain edge to domain edge connectivity): 
SDH HO VC - OTN HO ODU - ATM VP - MPSL-TP LSP - EVP - PBB-TE TESI
 
Furthermore in my view you have comparable roles of the following labels: 
 
- service/channel layer label: 
SDH TU timeslot - OTN LO ODU timeslot - ATM VCI - Ethernet VLAN ID - MPLS-TP
PW label
 
- tunnel/path layer label: 
SDH AU timeslot - OTN lambda - ATM VPI - MPLS-TP LSP label - Ethernet VLAN
ID - PBB-TE <ESP-DA,ESP-SA,ESP-VID> tuple.

As noted two weeks ago, E-LAN over SDH has introduced an additional service
layer on top of the traditional SDH service layer; i.e. the EVC layer. This
EVC layer has UNI-N to UNI-N connectivity. The VC-12 layer has now only EVC
termination to EVC switch point and EVC swithc point to EVC switch point
connectivity. This VC-12 connectivity could be 1-to-1 with the HOVC
connectivity. 
The VC-12 connections are not longer the service connections (this role has
been taken over by the EVC), and VC-12 connections are also not tunnel
connections (HO VC provides tunnel connections). These VC-12 connections are
only there to be able to carry the E-LAN services over timeslots of the HOVC
signals. 
For the case those VC-12 connections terminate at the same points as where
the HOVC connections terminate (i.e. SS-VC12) it would be possible to
disable the VC-12 OAM; i.e. the VC-12 OAM does not add anything to that
provided by the HOVC OAM and EVC OAM.
 
===========
 
For the case that MPLS-TP would perform the role of a service/channel layer
(see layer stack (2) below), then the requirements expressed by SPs at MEF
will be applicable/transitive to MPLS-TP's EVC replacement in my
opinion(i.e. to MPLS-TP MS-PW). 
 
If it is not the intention that an MPLS-TP construct replaces the EVC, then
the MEF service layer requirements do not apply to the MPLS-TP layer or
layers (which are located below the EVC layer). For this case I agree with
you.
 
============
 
I believe that there are four alternative MPLS-TP based packet transport
network layer stacks:
 
    (1)               (2)                (3)             (4)
------------    ---------------     -------------    -------
|   EVC    |    | EVC & MS-PW |     |    EVC    |    | EVC |
------------    ---------------     -------------    ------------
|   LSP    |    |     LSP     |     |    PW     |    |    PW    |
------------    ---------------     -------------    ------------
| T.Media  |    | Trans.Media |     |    LSP    |    |   LSP    |
------------    ---------------     -------------    ------------
                                    |  T.Media  |    |  T.Media |
                                    -------------    ------------
 
Which of these four stacks do we want to standardize for MPLS-TP based
packet transport networks?
 
For Ethernet VLAN based packet transport networks the layer stack is:
 
    (5)
------------
|   EVC    |
------------
|   EVP    |
------------
| T.Media  |
------------
 
For PBB-TE based packet transport networks the layer stack is:
 
    (6)
------------
|   EVC    |
------------
|   TESI   |
------------
| T.Media  |
------------
 
If we choose for MPLS-TP based packet transport network layer stacks (2) or
(4) we will deploy the PW layer as a service layer for p2p and p2mp customer
services. For the case one of the endpoints of a p2p customer service is
behind an Ethernet VLAN or PBB-TE domain, we will have to realize a
peer-interworking between PW and EVC to support the customer service. For
the case one or more of the p2mp customer service endpoints are behind an
Ethernet VLAN or PBB-TE domain, we will have to realize a peer-interworking
between PW and EVC to support the customer service.
 
Such peer interworking is not required when we choose for MPLS-TP based
packet transport network layer stacks (1) or (3).
 
Regards,
Maarten

  _____  

From: Greg Mirsky [mailto:[email-masked]] 
Sent: maandag 27 april 2009 20:47
To: Maarten Vissers
Cc: Thomas Nadeau; [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles (Re:
Associatedbidirectional transport path requirements)

Dear Maarten,

Regards,
Greg Mirsky

Tom,

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers

       Maartin,

       --Tom

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 13:01:22 +0200

Deborah,
 
> And the UNI/ENNI being discussed there is not comparable to your
definition.
 
I be more then happy if you give me alternative terms to UNI and ENNI.
 
Just use the example of a customer requesting a 2 Mbit/s service from the
SDH network, of which the first customer location is located behind the
network of operator A and the second endpoint is located behind the network
of operator B. Operator A and B interconnect via a STM-1 interface with each
other. The customer connects via a 2 Mbit/s G.703 interface with the
networks of operator A and B.
 
What term should I use for the interconnect of the customer to the networks
of operator A and B?
I.e. if it is not possible to call this the "UNI", what should it be called
then?
 
What term should I use for the interconnect of the networks of operator A
and B?
I.e. if it is not possible to call this the "ENNI", what should it be called
then?
 
Thanks for your help.
Regards,
Maarten
PS. Note that G.8012 defines UNI as follows: "An interface that is used for
the interconnection of customer equipment with a network element of the
transport network."
 
  _____  

From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: maandag 27 april 2009 23:00
To: Greg Mirsky; Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] We appear to be going around in circles
(Re:Associated bidirectional transport path requirements)

Maarten,

I think you have oversimplified the discussion in MEF and in so doing have
inaccurately summarized. As Greg says, MEF is oriented towards services
(SLA/SLS) and they also recognize that some operators only need simple
troubleshooting tools. Considering the on-going discussion in MEF, for the
service operators group, it is questionable if Y1731 should be used by
MPLS-TP as a baseline as it is considered inadequate. And I don’t see
AT&T’s requirements as any different from BT. I think we should follow
Adrian’s and Ben’s proposal to define the actual requirements for MPLS-TP
before replicating other technologies’ solutions.

Deborah

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: Monday, April 27, 2009 2:47 PM
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] We appear to be going around in circles
(Re:Associated bidirectional transport path requirements)

Dear Maarten,

Regards,
Greg Mirsky

Tom,

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers

       Maartin,

       --Tom

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 28 Apr 2009 11:52:02 -0400

Exactly – G707 defined the ENNI for SDH and G703/G704 for PDH. The PHY and framing is defined (per layer). This definition is very different from your earlier email. It does not require supporting PDH<->SDH interworking, or PDH OAM in SDH, or OAM interworking between a client/server as one of your earlier emails required:

>For this case it is necessary to develop ETH<>PW(client) layer 

>    interworking specifications. To limit the complexity of such layer 

>    network interworking, it is beneficial to select the MPLS-TP PW OAM 

>    use the Y.7131 OAM PDUs as proposed in draft-bhh-mpls-tp-oam-y1731. 

> I.e.

>    both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs

The interconnection of equipment (at one layer) should not put any restrictions on other layers.

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Tuesday, April 28, 2009 7:01 AM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements)

Deborah,

Just use the example of a customer requesting a 2 Mbit/s service from the SDH network, of which the first customer location is located behind the network of operator A and the second endpoint is located behind the network of operator B. Operator A and B interconnect via a STM-1 interface with each other. The customer connects via a 2 Mbit/s G.703 interface with the networks of operator A and B.

What term should I use for the interconnect of the customer to the networks of operator A and B?

I.e. if it is not possible to call this the "UNI", what should it be called then?

What term should I use for the interconnect of the networks of operator A and B?

I.e. if it is not possible to call this the "ENNI", what should it be called then?

Thanks for your help.

Regards,

Maarten

PS. Note that G.8012 defines UNI as follows: "An interface that is used for the interconnection of customer equipment with a network element of the transport network."

From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: maandag 27 april 2009 23:00
To: Greg Mirsky; Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements)

Maarten,

Deborah

Dear Maarten,

Regards,
Greg Mirsky

Tom,

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers

       Maartin,

       --Tom

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 29 Apr 2009 09:22:47 +0200

Deborah,
 
Thank you for confirming that we can speak about ENNI for non-IP layer
interconnects. As you indicate, an ENNI also exists when we interconnect two
SDH admin domains via an STM-N.
 
Do you also agree that we can speak about an ENNI when we interconnect a
Metro/Carrier Ethernet Network admin domain A with a Metro/Carrier Etherent
Network admin domain B via an 802.3 interface over which the EVC layer is
transported?
 
Regards,
Maarten

  _____  

From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: dinsdag 28 april 2009 17:52
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] We appear to be going around in circles
(Re:Associated bidirectional transport path requirements)

Exactly – G707 defined the ENNI for SDH and G703/G704 for PDH. The PHY and
framing is defined (per layer). This definition is very different from your
earlier email. It does not require supporting PDH<->SDH interworking, or PDH
OAM in SDH, or OAM interworking between a client/server as one of your

>    both Ethernet and MPLS-TP will then use e.g. CCM OAM PDUs

The interconnection of equipment (at one layer) should not put any
restrictions on other layers.

Deborah,

Thanks for your help.

Regards,

Maarten

  _____  

Maarten,

Deborah

Dear Maarten,

Regards,
Greg Mirsky

Tom,

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers

       Maartin,

       --Tom

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 29 Apr 2009 11:05:31 -0400

Maarten,

I only have confirmed that what you have given as an example of an ENNI below is G707 and G704. You missed the point. This is a typical ITU interface standard. It can be used as an INNI, ENNI, or UNI. Since you are twisting words, I’ll try to be clearer.

Yes, we need interface standards. If we have standards and have defined the technology properly, we do not need your “interworking ENNI”.  You have twisted the definition of a standard interface used between (hopefully) all equipment, within a domain and between domains, to rationalize your “ENNI”. Two operators (or Forum) agreeing on a physical encapsulation, J1, vlans, or label to be used may be described in the industry as interworking, but then it can be said that every interface is interworking. The fiber connectors are interworking. Instead of saying, I’m connecting the fiber, we will say, we are interworking the fiber. This is silly. Rather than use a much hyped non-specific term, here, in ITU and IETF, we should be specific. 

The ENNI/UNIs defined in MPLS Forum and MEF are a profile of existing standards. They provide a consistent interpretation of an existing standard for the members of the Forum (i.e. improved readability for the members, as we all know, ITU Recommendations and IETF RFCs are often not standalone documents or not easy reading for non-involved readers). It is questionable for IETF or ITU to define an ENNI or UNI as it will be difficult for all the members to agree – otherwise all the options should not be in the original standard if they were not needed.

Connecting two networks together using a standard physical layer is not really an ENNI (as Neil has said over and over). If we start defining UNI/ENNI/INNI for all the technologies in ITU and IETF, we will have an operational nightmare.

Deborah

From: Maarten Vissers [mailto:[email-masked]] 
Sent: Wednesday, April 29, 2009 3:23 AM
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: [email-masked]
Subject: RE: [mpls-tp] We appear to be going around in circles (Re:Associated bidirectional transport path requirements)

Deborah,

Thank you for confirming that we can speak about ENNI for non-IP layer interconnects. As you indicate, an ENNI also exists when we interconnect two SDH admin domains via an STM-N.

Do you also agree that we can speak about an ENNI when we interconnect a Metro/Carrier Ethernet Network admin domain A with a Metro/Carrier Etherent Network admin domain B via an 802.3 interface over which the EVC layer is transported?

Regards,

Maarten

Deborah,

Thanks for your help.

Regards,

Maarten

Maarten,

Deborah

Dear Maarten,

Regards,
Greg Mirsky

Tom,

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers

       Maartin,

       --Tom

---

From: <[email-masked]>
Date: Wed, 29 Apr 2009 16:08:33 +0100

Well said Deborah.  regards, Neil

	From: [email-masked] [mailto:[email-masked]] On Behalf Of BRUNGARD, DEBORAH A, ATTLABS
	Sent: 29 April 2009 16:06
	To: Maarten Vissers
	Cc: [email-masked]
	Subject: Re: [mpls-tp] We appear to be going around in circles(Re:Associated bidirectional transport path requirements)

	Maarten,

	Deborah

	Deborah,

	Regards,

	Maarten

	Deborah,

	Thanks for your help.

	Regards,

	Maarten

	Maarten,

	Deborah

	Dear Maarten,
	
	Regards,
	Greg Mirsky

	Tom,

	

	
	Regards,
	Maarten

	-----Original Message-----
	From: Thomas Nadeau [mailto:[email-masked]]
	Sent: vrijdag 24 april 2009 15:35
	To: Maarten Vissers

	       Maartin,

	

	       --Tom

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 29 Apr 2009 18:06:35 +0200

Deborah,
 
You are going far beyond my question. Let me try to clarify by using a
figure, In this figure there is an admin domain A and an admin domain B.
These two domains are interconnected via an 802.3 interface over which the
EVC layer is continued. My question is how we should refer to this interface
between domains A and B? Is this interface referred to as ENNI? If it is not
referred to as ENNI, what is then the name to use for this class of
interfaces?

    (A)                     (B) 
------------------------------------
|   EVC                      EVC   |
------------------------------------
|  Tunnel  |   |802.3|   | Tunnel  |
------------   -------   ----------- 
| T.Media  |      ^      | T.Media |
------------      |      -----------
                  | 
                 ENNI?
 
Regards,
Maarten

  _____  

From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: woensdag 29 april 2009 17:06
To: Maarten Vissers
Cc: [email-masked]
Subject: RE: [mpls-tp] We appear to be going around in circles
(Re:Associated bidirectional transport path requirements)

Maarten,

I only have confirmed that what you have given as an example of an ENNI
below is G707 and G704. You missed the point. This is a typical ITU
interface standard. It can be used as an INNI, ENNI, or UNI. Since you are
twisting words, I’ll try to be clearer.

Yes, we need interface standards. If we have standards and have defined the
technology properly, we do not need your “interworking ENNI”.  You have
twisted the definition of a standard interface used between (hopefully) all
equipment, within a domain and between domains, to rationalize your
“ENNI”. Two operators (or Forum) agreeing on a physical encapsulation, J1,
vlans, or label to be used may be described in the industry as interworking,
but then it can be said that every interface is interworking. The fiber
connectors are interworking. Instead of saying, I’m connecting the fiber,
we will say, we are interworking the fiber. This is silly. Rather than use a
much hyped non-specific term, here, in ITU and IETF, we should be specific. 

The ENNI/UNIs defined in MPLS Forum and MEF are a profile of existing
standards. They provide a consistent interpretation of an existing standard
for the members of the Forum (i.e. improved readability for the members, as
we all know, ITU Recommendations and IETF RFCs are often not standalone
documents or not easy reading for non-involved readers). It is questionable
for IETF or ITU to define an ENNI or UNI as it will be difficult for all the
members to agree – otherwise all the options should not be in the original
standard if they were not needed.

Connecting two networks together using a standard physical layer is not
really an ENNI (as Neil has said over and over). If we start defining
UNI/ENNI/INNI for all the technologies in ITU and IETF, we will have an
operational nightmare.

Deborah

Deborah,

Regards,

Maarten

  _____  

Deborah,

Thanks for your help.

Regards,

Maarten

  _____  

Maarten,

Deborah

Dear Maarten,

Regards,
Greg Mirsky

Tom,

Regards,
Maarten

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]]
Sent: vrijdag 24 april 2009 15:35
To: Maarten Vissers

       Maartin,

       --Tom

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 29 Apr 2009 14:23:47 -0400

Dear Maarten,
in my view the answer to your question depends upon answer to "What Tunnel A
and Tunnel B are?"

Regards,
Greg

2009/4/29 Maarten Vissers <[email-masked]>

> *From:* BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]]
> *Sent:* woensdag 29 april 2009 17:06
>
> *To:* Maarten Vissers
> *Cc:* [email-masked]
> *Subject:* RE: [mpls-tp] We appear to be going around in circles
> equipment, within a domain and between domains, to rationalize your “ENNI”.
> Two operators (or Forum) agreeing on a physical encapsulation, J1, vlans, or
> label to be used may be described in the industry as interworking, but then
> it can be said that every interface is interworking. The fiber connectors
> are interworking. Instead of saying, I’m connecting the fiber, we will say,
> we are interworking the fiber. This is silly. Rather than use a much hyped
> non-specific term, here, in ITU and IETF, we should be specific.
>
>
>
> *From:* Maarten Vissers [mailto:[email-masked]]
> *Sent:* Wednesday, April 29, 2009 3:23 AM
> *Subject:* RE: [mpls-tp] We appear to be going around in circles
> *From:* BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]]
> *Sent:* dinsdag 28 april 2009 17:52
> *To:* Maarten Vissers
> *Cc:* [email-masked]
> *Subject:* RE: [mpls-tp] We appear to be going around in circles
> *From:* Maarten Vissers [mailto:[email-masked]]
> *Sent:* Tuesday, April 28, 2009 7:01 AM
> *Subject:* RE: [mpls-tp] We appear to be going around in circles
> PS. Note that G.8012 defines UNI as follows: "An interface that is used
> for the interconnection of customer equipment with a network element of the
> transport network."
>
>
> *From:* BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]]
> *Sent:* maandag 27 april 2009 23:00
> *To:* Greg Mirsky; Maarten Vissers
> *Cc:* [email-masked]
> *Subject:* RE: [mpls-tp] We appear to be going around in circles
> MPLS-TP as a baseline as it is considered inadequate. And I don’t see AT&T’s
> requirements as any different from BT. I think we should follow Adrian’s and
> Ben’s proposal to define the actual requirements for MPLS-TP before
> replicating other technologies’ solutions.
>
>
>
> Behalf Of *Greg Mirsky
> *Sent:* Monday, April 27, 2009 2:47 PM
> *To:* Maarten Vissers
> *Cc:* [email-masked]
> *Subject:* Re: [mpls-tp] We appear to be going around in circles

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 30 Apr 2009 08:34:56 -0700

Deborah,

I agree completely.  As you point out, there can be interfaces between peer networks that support the same technologies (e.g., ATM-ATM, FR-FR, SDH-SDH, MPLS-MPLS, etc), and these interfaces are typically termed NNIs.

What Maarten seems to be doing is conflating NNIs and interworking functions between heterogeneous non-top of stack technologies, which have nothing whatever to do with NNIs and which may or may not be possible, but aren't worth the trouble.

Thanks,

John

> Sent: Wednesday, April 29, 2009 8:06 AM
> To: Maarten Vissers
> Cc: [email-masked]
> I only have confirmed that what you have given as an example 
> of an ENNI below is G707 and G704. You missed the point. This 
> is a typical ITU interface standard. It can be used as an 
> INNI, ENNI, or UNI. Since you are twisting words, I’ll try to 
> be clearer.
> 
>  
> 
> Yes, we need interface standards. If we have standards and 
> have defined the technology properly, we do not need your 
> “interworking ENNI”.  You have twisted the definition of a 
> standard interface used between (hopefully) all equipment, 
> within a domain and between domains, to rationalize your 
> “ENNI”. Two operators (or Forum) agreeing on a physical 
> encapsulation, J1, vlans, or label to be used may be 
> described in the industry as interworking, but then it can be 
> said that every interface is interworking. The fiber 
> connectors are interworking. Instead of saying, I’m 
> connecting the fiber, we will say, we are interworking the 
> fiber. This is silly. Rather than use a much hyped 
> The ENNI/UNIs defined in MPLS Forum and MEF are a profile of 
> existing standards. They provide a consistent interpretation 
> of an existing standard for the members of the Forum (i.e. 
> improved readability for the members, as we all know, ITU 
> Recommendations and IETF RFCs are often not standalone 
> documents or not easy reading for non-involved readers). It 
> is questionable for IETF or ITU to define an ENNI or UNI as 
> it will be difficult for all the members to agree – otherwise 
> all the options should not be in the original standard if 
> they were not needed.
> 
>  
> 
> Connecting two networks together using a standard physical 
> layer is not really an ENNI (as Neil has said over and over). 
> If we start defining UNI/ENNI/INNI for all the technologies 
> in ITU and IETF, we will have an operational nightmare.
> 
>  
> 
> Deborah
> 
>  
> 
> Subject: RE: [mpls-tp] We appear to be going around in 
> Thank you for confirming that we can speak about ENNI for 
> non-IP layer interconnects. As you indicate, an ENNI also 
> exists when we interconnect two SDH admin domains via an STM-N.
> 
>  
> 
> Do you also agree that we can speak about an ENNI when we 
> interconnect a Metro/Carrier Ethernet Network admin domain A 
> with a Metro/Carrier Etherent Network admin domain B via an 
> 802.3 interface over which the EVC layer is transported?
> 
>  
> 
> Regards,
> 
> Maarten
> 
>  
> 
> Subject: RE: [mpls-tp] We appear to be going around in 
> Exactly – G707 defined the ENNI for SDH and G703/G704 for 
> PDH. The PHY and framing is defined (per layer). This 
> definition is very different from your earlier email. It does 
> not require supporting PDH<->SDH interworking, or PDH OAM in 
> SDH, or OAM interworking between a client/server as one of 
> your earlier emails required:
> 
>  
> 
> Subject: RE: [mpls-tp] We appear to be going around in 
> Just use the example of a customer requesting a 2 Mbit/s 
> service from the SDH network, of which the first customer 
> location is located behind the network of operator A and the 
> second endpoint is located behind the network of operator B. 
> Operator A and B interconnect via a STM-1 interface with each 
> other. The customer connects via a 2 Mbit/s G.703 interface 
> with the networks of operator A and B.
> 
>  
> 
> PS. Note that G.8012 defines UNI as follows: "An interface 
> that is used for the interconnection of customer equipment 
> with a network element of the transport network."
> 
>  
> 
> Subject: RE: [mpls-tp] We appear to be going around in

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 30 Apr 2009 09:19:05 -0700

Hi,

As an example of the difference between an NNI and an interworking function, see the following:

http://www.ipmplsforum.org/frame/Approved/FRF.2/FRF_2_2-final.pdf

http://www.ipmplsforum.org/frame/Approved/FRF.8/FRF.8.2.pdf 

with which David and Andy may have some familiarity.

Thanks,

John 
> From: Drake, John E 
> Sent: Thursday, April 30, 2009 8:35 AM
> To: BRUNGARD, DEBORAH A, ATTLABS; Maarten Vissers
> Cc: [email-masked]
> I agree completely.  As you point out, there can be 
> interfaces between peer networks that support the same 
> technologies (e.g., ATM-ATM, FR-FR, SDH-SDH, MPLS-MPLS, etc), 
> and these interfaces are typically termed NNIs.
> 
> What Maarten seems to be doing is conflating NNIs and 
> interworking functions between heterogeneous non-top of stack 
> technologies, which have nothing whatever to do with NNIs and 
> which may or may not be possible, but aren't worth the trouble.
> 
> Thanks,
> 
> John
> 
> > I only have confirmed that what you have given as an example of an 
> > ENNI below is G707 and G704. You missed the point. This is 
> a typical 
> > ITU interface standard. It can be used as an INNI, ENNI, or 
> UNI. Since 
> > you are twisting words, I’ll try to be clearer.
> > 
> >  
> > 
> > Yes, we need interface standards. If we have standards and have 
> > defined the technology properly, we do not need your “interworking 
> > ENNI”.  You have twisted the definition of a standard 
> interface used 
> > between (hopefully) all equipment, within a domain and between 
> > domains, to rationalize your “ENNI”. Two operators (or 
> Forum) agreeing 
> > on a physical encapsulation, J1, vlans, or label to be used may be 
> > described in the industry as interworking, but then it can be said 
> > that every interface is interworking. The fiber connectors are 
> > interworking. Instead of saying, I’m connecting the fiber, we will 
> > say, we are interworking the fiber. This is silly. Rather 
> than use a 
> > > On 23/04/2009 07:23, "[email-masked]" 
> <[email-masked]>
> > > wrote:
> > >
> > >> ben: