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

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 18:01:24 +0200

Shahram,
 
A transport equipment contains many devices (chips) and a lot of software. A
single configuration command from a management system may result in the
configuration of multiple devices and software modules in the transport
equipment. The equipment manufacturer develops its product such that there
is consistent configuration amoung these devices and software modules. That
is why from outside the black box you can view this as a single
configuration.
 
REgards,
Maarten

  _____  

From: Shahram Davari [mailto:[email-masked]] 
Sent: maandag 27 april 2009 16:29
To: 'Maarten Vissers'; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] Associated bidirectional transport path requirements

Maarten,
 
In MPLS forwarding (and consequently in MPLS-TP forwarding), no binding is
kept at adaptation sink function. In other words top label is popped and
lower label is looked up independent of what the popped label was. But to
generate AIS you require such binding to be kept in memory so that you can
generate AIS on the client LSPs.
 
So I disagree with your analysis here. Because the client/server binding for
forwarding purpose is kept at source point and not sink point.
I agree with Andy, and the chips that I have seen that generate AIS,
generate it using an independent client/server binding table that must be
configured which may be miss-configured.
 
Regards,
Shahram
 
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: April-27-09 9:43 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] Associated bidirectional transport path requirements
 
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 
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: 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...

  _____  

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
One hopes this is because this is because the service is working properly. 
 
[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 
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: 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,
 
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 
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: 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
> 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 
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 

收件人
<[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 
  
  _____  

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 

"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

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.

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 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Drake, John E
> Sent: 17 April 2009 20:02
> To: BUSI ITALO; Alexander Vainshtein; Maarten Vissers
> Cc: [email-masked]
> Subject: Re: [mpls-tp] Associated bidirectional transport path 
> requirements
> 
> 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
> > -----Original Message-----
> > 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]
> > Subject: RE: [mpls-tp] Associated bidirectional transport path 
> > requirements
> > 
> > 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
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Drake, John E
> > > Sent: Thursday, April 16, 2009 8:00 PM
> > > To: Alexander Vainshtein; Maarten Vissers
> > > Cc: [email-masked]
> > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
> > > requirements
> > > 
> > > 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.
> > > 
> > > > -----Original Message-----
> > > > From: Alexander Vainshtein
> > > [mailto:[email-masked]]
> > > > Sent: Thursday, April 16, 2009 9:57 AM
> > > > To: Maarten Vissers
> > > > Cc: [email-masked]
> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
> > > > requirements
> > > > 
> > > > 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,
> > > > 
> > > > >> <quote>
> > > > >>      The intermediate nodes (including MEPs, MIPs and
> > > > other internal
> > > > >>       functions as appropriate) of a co-routed
> > > > bidirectional transport
> > > > >>       path at each (sub-)layer MUST be aware of the pairing
> > > > >>       relationship of the forward and the backward
> > > > directions of that
> > > > >>       transport path.
> > > > >> <end quote>
> > > > >
> > > > > There is no way this is a functional requirement. That
> > > is, there is
> > > > > *nothing* that can be observed from a black box point of
> > > view that
> > > > > results from adhering to this requirement.
> > > > 
> > > > 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,
> > > > 
> > > > > Unfortunately I cannot fully agree with your statement:
> > > > >
> > > > > <quote>
> > > > >     From the point of view of hardware, co-routed
> > > bidirectional LSPs
> > > > >     are a special case of associated bidirectional LSPs.
> > > > > <end quote>
> > > > >
> > > > > This statement would be obviously correct, were it not for
> > > > Requirement
> > > > > 34 in the latest MPLS-TP requirements draft
> > > > 
> > > > OK. Got it.
> > > > 
> > > > But what is this doing in the data plane requirements section?
> > > > 
> > > > In fact, what is this requirement actually saying?
> > > > 
> > > > > <quote>
> > > > >      The intermediate nodes (including MEPs, MIPs and
> > > other internal
> > > > >       functions as appropriate) of a co-routed
> > > > bidirectional transport
> > > > >       path at each (sub-)layer MUST be aware of the pairing
> > > > >       relationship of the forward and the backward
> > > > directions of that
> > > > >       transport path.
> > > > > <end quote>
> > > > 
> > > > There is no way this is a functional requirement. That
> > is, there is
> > > > *nothing* that can be observed from a black box point of
> > view that
> > > > results from adhering to this requirement.
> > > > 
> > > > Therefore it could be assumed that this requirement is met by 
> > > > configuring some data plane database component through the 
> > > > management plane. The database component is not used
> for anything
> > > > except to satisfy this requirement for "awareness".
> > > > 
> > > > Ben! Can we please try to rewrite this requirement in terms of 
> > > > behavior?
> > > > 
> > > > > Please note that Requirement 34 is the ONLY item in the
> > > > list that is
> > > > > specific for co-routed bidirectional LSPs. (The pairing
> > > > requirements
> > > > > at end points for co-routed and associated bidirectional
> > > paths are
> > > > > exactly the same even if they appear in two different
> > > items in the
> > > > > requirements' list).
> > > > > In other words, without Requirement 34 the notion of
> co-routed
> > > > > bidirectional paths would be void of any data plane content.
> > > > >
> > > > > The somewhat vague scope of this requirement ("other internal 
> > > > > functions as appropriate") creates a suspicion that HW
> > > > support of the
> > > > > pairing awareness may be required in order to comply with it.
> > > > 
> > > > The entirety of the bracketted text "(including MEPs,
> > MIPs and other
> > > > internal functions as appropriate)" should be deleted. It
> > does not
> > > > add to "The intermediate nodes."
> > > > 
> > > > > The following text in the draft increases this suspicion:
> > > > >
> > > > > <quote>
> > > > >   Tandem Connection: A tandem connection is an
> > arbitrary part of a
> > > > >   transport path that can be monitored (via OAM)
> > > > independently from the
> > > > >   end-to-end monitoring (OAM).  It may be a monitored
> > segment or a
> > > > >   monitored concatenated segment of a transport path.  
> > The tandem
> > > > >   connection may also include the forwarding engine(s) of
> > > > the node(s)
> > > > >   at the edge(s) of the segment or concatenated segment.
> > > > > <end quote>
> > > > 
> > > > Actually, I am quite fed up about this persistent
> > insistence on the
> > > > inclusion of "Tandem Connection." The definition within
> > the ITU-T of
> > > > this term is poorly specified and comes from the
> monitoring of a
> > > > path that is parallel (i.e. tandem) to the data path being 
> > > > monitored. This definition of TC seems to be at variance,
> > and would
> > > > be if the ACH was actually in band.
> > > > 
> > > > > Doesn't "forwarding engine" sound like hardware to you?
> > > > 
> > > > Yes, but so what?
> > > > 
> > > > > IMHO it is worth noting that neither the MPLS-TP
> > > Requirements draft
> > > > > nor the MPLS-TP OAM requirements one
> > > > > 
> > > > 
> > > 
> > 
> (http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requiremen
> > > > > ts-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-fr
> > > > amework-00.txt
> > > > ).
> > > > 
> > > > Right.
> > > > Let's just get rid of an unnecessary term and bring all
> the I-Ds
> > > > into line.
> > > > 
> > > > > The bottom line, IMHO, is that some clarity regarding
> > > co-routed vs.
> > > > > associated
> > > > > bidirectional paths is still required. One way to provide
> > > > that could
> > > > > be by explicitly limiting Requirement 34 to specific
> > > functionality.
> > > > 
> > > > Agreed.
> > > > 
> > > > Adrian
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ________________________________________
> > > > From: Adrian Farrel [[email-masked]]
> > > > Sent: Thursday, April 16, 2009 12:13 AM
> > > > To: Alexander Vainshtein; Lou Berger; BUSI ITALO
> > > > Cc: [email-masked]
> > > > Subject: Re: [mpls-tp] Associated bidirectional transport path 
> > > > requirements
> > > > 
> > > > Hi Sasha,
> > > > 
> > > > Not really sure whether you are misrepresenting anyone, but...
> > > > 
> > > > > 1. My reading of  one of Ben's  messages is that associated 
> > > > > bidirectional paths are the only types of paths that can be
> > > > created in
> > > > > the existing networks; "true" co-routed bidirectional paths
> > > > will have
> > > > > to wait until (if ever) new equipment becomes available.
> > > > 
> > > > This is clearly nonsense!
> > > > From the point of view of hardware, co-routed
> > bidirectional LSPs are
> > > > a special case of associated bidirectional LSPs.
> > > > 
> > > > If you can set up two unidirectional LSPs (e.g. using the
> > management
> > > > plane) you can surely set up a co-routed
> > > bidirectional LSP.
> > > > 
> > > > There are shipping solutions that achieve co-routed
> bidirectional
> > > > LSPs using the control plane. These either use the GMPLS
> > (which is
> > > > cleaner) or non-standard proprietary solutions (which is
> > messy but
> > > > functional).
> > > > 
> > > > But (of course) the management plane or control plane
> > solutions have
> > > > nothing to do with availability of equipment as they 
> are software
> > > > solutions.
> > > > 
> > > > > 2. My reading of one of Neil's messages is that the actual
> > > > driver for
> > > > > co-routed bidirectional paths may be experience with existing 
> > > > > transport networks rather than any specific benefit.
> > > > 
> > > > Isn't that the case with 75% of the MPLS-TP requirements?
> > > > Which is not to say it is a bad thing.
> > > > 
> > > > A large driver for MPLS-TP is to give the packet network
> > the look,
> > > > feel, and behavioral characteristics of a "legacy"
> > > > transport network.
> > > > 
> > > > > Based on these observations, I'd guess (FWIW) that:
> > > > > * associated bidirectional paths are, at least for the time
> > > > >    being, the most important type of bidirectional paths in
> > > > >    MPLS-TP
> > > > 
> > > > I think that is wrong both given my statement above, and
> > given that
> > > > other upgrades to existing MPLS solutions will be
> needed to reach
> > > > the full function level of MPLS-TP.
> > > > 
> > > > > * they had a good chance to remain the only type of
> > bidirectional
> > > > >   paths in  real deployments.
> > > > 
> > > > I don't see what that follows from.
> > > > 
> > > > Cheers,
> > > > Adrian
> > > > 
> > > > _______________________________________________
> > > > mpls-tp mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > 
> > > > _______________________________________________
> > > > mpls-tp mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > 
> > > > 
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > 
> > 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

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

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