Subject: [mpls-tp] Lifespan of ingress and egress MIPs: comparison with 802.1ag

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 13 Nov 2009 04:13:12 +0200

Luca and all,
It may be of some interest and relevance to compare the definition of the egress MIP lifespan in MPLS-TP (yet to be formalized, presumably in the MPLS-TP OAM requirements and/or framework documents) with the de-facto behavior of MIPs in IEEE 802.1ag-2007.

802.1ag does not explicitly specify lifespan of MIPs. However, it specifies that ID of the egress MIP is sent to the Link Trace originator (in the appropriate TLV in the LTR message) if the switch FIB lookup discovers a single egress interface for the Target MAC in the LTM, and a MIP has been configured on this interface.

802.1ag is (just as everything else in 802.1) about Ethernet learning bridges. The FIB of learning bridges is normally populated by the MAC learning process, and, when port on such a bridge goes down, all the addresses learned from this port are flushed.

The conclusion:

>From the Link Trace prospective, the lifespan of MIP in 802.1ag is defined by the lifespan of the port on which it resides. When the port goes down, all MIPs associated with it, disappear.

As I have said at the mike today, the same situation exists in IP today (if we consider an IP address of an interface as an equivalent of MIP).

IMHO and FWIW we need some very strong and explicit motivation to change this common behavior for MPLS-TP.

My 2c,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 13 Nov 2009 09:04:24 +0100

Sasha,
 
If an interface port X contains an ETH MIP for a VLAN Y is determine by the
following:
1) VLAN Y is registered on port X (e.g. using VID 10)
2) Port X is capable to support ETH MIP functions
3) the operator has activated ETH MIP function associated with VID=10 on
port X for VLAN Y.
 
When the above three conditions are fulfilled the ETH MIP function with
VID=10 will be active as long as VLAN Y is using port X.
 
It is possible to reroute VLAN Y such that it will not longer use port X, or
to tear down VLAN Y. 
If this happens, then the ETH MIP function with VID=10 on port X assigned to
VLAN Y is disabled.
 
Rerouting of VLAN Y is possible under control of a management system or a
control plane (e.g. xSTP/xVRP or GMPLS).
 
When a VLAN Z is set up using VID=10 on port X the ETH MIP function with
VID=10 can be activated again. It will then be a member of VLAN Z.
 
Conclusion: 
 
A port X may or may not support ETH MIP functions. If port X supports ETH
MIP functions it will do so for ever.
 
ETH MIP functions on a port X may be active or inactive.
 
The VLAN connection management process can activate an ETH MIP function on a
port X for a VLAN when it set up the VLAN over this port X.
The lifespan of this ETH MIP within VLAN Y is the lifespan of VLAN Y on port
X.

Further behaviour:
 
When a port X fails or is removed from the node (without changing the
routing of the VLAN), the ETH MIP function is not longer reachable.
 
When the VLAN configuration error occurs which disconnects port X from the
VLAN, then the ETH MIP function on port X is not longer reachable. 
 
In both cases the ETH MEP function or functions downstream of the ETH MIP on
port X are then also disconnected from the rest of the VLAN. 
This will cause the detection of Loss of CCM and will trigger a fault
localization application to discover the faulty node.
 
If the port X failed or was removed, then there will be a port alarm. If
there is no port alarm, then there is a VLAN config error and the faulty
node can be discovered via sending a series of unicast LBM OAM frames to the
different ETH MIP functions between an ETH MEP and a disconnected ETH MEP.
The first ETH MIP that does not respond with a LBR OAM frame tells you where
the disconnect is. If the MIP is an egress MIP, then the config error is in
the same node; if the MIP is an ingress MIP, then the config error is in the
previous node (which does not have an egress MIP).

General:
 
MIP and also MEP functions are supported by ports.
 
An inactive MIP or MEP function on a port may be activated when a p2p or mp
connection is set up over this port. 
An active MIP or MEP function on a port is deactivated when the p2p or mp
connection is removed from this port.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: vrijdag 13 november 2009 3:13
To: Luca Martini
Cc: BUSI ITALO; [email-masked]
Subject: [mpls-tp] Lifespan of ingress and egress MIPs: comparison with
802.1ag

Luca and all,
It may be of some interest and relevance to compare the definition of the
egress MIP lifespan in MPLS-TP (yet to be formalized, presumably in the
MPLS-TP OAM requirements and/or framework documents) with the de-facto
behavior of MIPs in IEEE 802.1ag-2007.
 
802.1ag does not explicitly specify lifespan of MIPs. However, it specifies
that ID of the egress MIP is sent to the Link Trace originator (in the
appropriate TLV in the LTR message) if the switch FIB lookup discovers a
single egress interface for the Target MAC in the LTM, and a MIP has been
configured on this interface.
 
802.1ag is (just as everything else in 802.1) about Ethernet learning
bridges. The FIB of learning bridges is normally populated by the MAC
learning process, and, when port on such a bridge goes down, all the
addresses learned from this port are flushed.
 
The conclusion: 
 
>From the Link Trace prospective, the lifespan of MIP in 802.1ag is defined
by the lifespan of the port on which it resides. When the port goes down,
all MIPs associated with it, disappear.
 
As I have said at the mike today, the same situation exists in IP today (if
we consider an IP address of an interface as an equivalent of MIP).
 
IMHO and FWIW we need some very strong and explicit motivation to change
this common behavior for MPLS-TP.
 
My 2c,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 14 Nov 2009 06:33:18 +0200

Maarten,
My understanding of the problem Luca and others have been trying to solve (but, probably, did not spell out) is differentiation between a failure at the egress side of Node X and failure of  its adjacent (on that side) Node Y.

What i have been trying to say is that, in certain cases, when Node Y (as a whole) goes down, Node X perceives that as the failure of its port  leading to Node Y. The behavior of ETH MIPs you've presented matches my understanding of 802.1ag and, IMO, means, that the original differentiation problem will not be solved with ETH MIPs (which are always per interface BTW). The same applies to IP if consider an IP address of an interface as an analog of a per-interface MIP.

Based on this I suspect that per-interface MIPs in MPLS-TP will not resolve this problem either.
It then remains to be seen which problems these mechanisms do resolve (compared with per-node MIPs which to me are equivalent to IP address of a loopback interface of a router).

Regards,
     Sasha
________________________________
From: Maarten Vissers [[email-masked]]
Sent: Friday, November 13, 2009 10:04 AM
To: Alexander Vainshtein; 'Luca Martini'
Cc: 'BUSI ITALO'; [email-masked]
Subject: RE: [mpls-tp] Lifespan of ingress and egress MIPs: comparison with 802.1ag

Sasha,

If an interface port X contains an ETH MIP for a VLAN Y is determine by the following:
1) VLAN Y is registered on port X (e.g. using VID 10)
2) Port X is capable to support ETH MIP functions
3) the operator has activated ETH MIP function associated with VID=10 on port X for VLAN Y.

When the above three conditions are fulfilled the ETH MIP function with VID=10 will be active as long as VLAN Y is using port X.

It is possible to reroute VLAN Y such that it will not longer use port X, or to tear down VLAN Y.
If this happens, then the ETH MIP function with VID=10 on port X assigned to VLAN Y is disabled.

Rerouting of VLAN Y is possible under control of a management system or a control plane (e.g. xSTP/xVRP or GMPLS).

When a VLAN Z is set up using VID=10 on port X the ETH MIP function with VID=10 can be activated again. It will then be a member of VLAN Z.

Conclusion:

A port X may or may not support ETH MIP functions. If port X supports ETH MIP functions it will do so for ever.

The VLAN connection management process can activate an ETH MIP function on a port X for a VLAN when it set up the VLAN over this port X.
The lifespan of this ETH MIP within VLAN Y is the lifespan of VLAN Y on port X.

Further behaviour:

When a port X fails or is removed from the node (without changing the routing of the VLAN), the ETH MIP function is not longer reachable.

When the VLAN configuration error occurs which disconnects port X from the VLAN, then the ETH MIP function on port X is not longer reachable.

In both cases the ETH MEP function or functions downstream of the ETH MIP on port X are then also disconnected from the rest of the VLAN.
This will cause the detection of Loss of CCM and will trigger a fault localization application to discover the faulty node.

If the port X failed or was removed, then there will be a port alarm. If there is no port alarm, then there is a VLAN config error and the faulty node can be discovered via sending a series of unicast LBM OAM frames to the different ETH MIP functions between an ETH MEP and a disconnected ETH MEP. The first ETH MIP that does not respond with a LBR OAM frame tells you where the disconnect is. If the MIP is an egress MIP, then the config error is in the same node; if the MIP is an ingress MIP, then the config error is in the previous node (which does not have an egress MIP).

General:

An inactive MIP or MEP function on a port may be activated when a p2p or mp connection is set up over this port.
An active MIP or MEP function on a port is deactivated when the p2p or mp connection is removed from this port.

Regards,
Maarten

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: vrijdag 13 november 2009 3:13
To: Luca Martini
Cc: BUSI ITALO; [email-masked]
Subject: [mpls-tp] Lifespan of ingress and egress MIPs: comparison with 802.1ag

Luca and all,

My 2c,
     Sasha

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 16 Nov 2009 09:02:15 +0100

Sasha,
 
In the discussion so far we have been looking into detection of faults and
degradations of individual connections. Besides this per connection
detection there are the detection of equipment faults, e.g. detection of a
failed port card, switch card, adjunct card, processor card, power supply
card, data comm card, backplane, loss of input power, loss of management
association, etc. Transport network equipment contains equipment defect
detectors that will be able to detect a certain percentage of equipment
faults/degradations. Not all faults are detectable however, so there is
always a probability that there is a fault on an egress port of node X after
the MIP function. If this fault would interrupt the transmission, then the
input port on the next node (Y) will detect a loss of input signal. Any loss
of input signal alarm will result in the checking of the previous
transmitter (on egress port of node X), cable between X and Y and receiver
(on ingress port of node Y). Such fault will as such not rely on the fault
localisation capability provided by MIP functions.
 
MIP functions help to locate connectivity faults (and degradations) within
individual connections.
 
Per-node MIP functions are located outside the connection, and are not
accessible from a connection.
 
As you know, 802.1ag and Y.1731/G.8010 have specified MIP and half-MIP
functions. 
Half-MIP functions support an ingress MIP, not an egress MIP. 
Those half-MIP functions have been introduced to describe the MIP capability
which could be added to some existing Ethernet switch ports after a
software/firmware upgrade. 
Newly designed Ethernet switch ports will be equipped with MIP functions,
supporting ingress and egress MIP capabilities.
 
I would expect that a similar evolution can be expected from MPLS-TP
switches; initially some limited OAM capabilities (including e.g. half-MIP)
can be added to the existing MPLS port cards, while new designs will be able
to support full OAM capabilities, including MIP functions. Ethernet is just
a few years ahead, as Y.1731 was approved in May 2006.
 
Regards,
Maarten

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: zaterdag 14 november 2009 5:33
To: Maarten Vissers
Cc: 'BUSI ITALO'; [email-masked]; 'Luca Martini'
Subject: RE: [mpls-tp] Lifespan of ingress and egress MIPs: comparison
with802.1ag

Maarten,
My understanding of the problem Luca and others have been trying to solve
(but, probably, did not spell out) is differentiation between a failure at
the egress side of Node X and failure of  its adjacent (on that side) Node
Y.
 
What i have been trying to say is that, in certain cases, when Node Y (as a
whole) goes down, Node X perceives that as the failure of its port  leading
to Node Y. The behavior of ETH MIPs you've presented matches my
understanding of 802.1ag and, IMO, means, that the original differentiation
problem will not be solved with ETH MIPs (which are always per interface
BTW). The same applies to IP if consider an IP address of an interface as an
analog of a per-interface MIP.
 
Based on this I suspect that per-interface MIPs in MPLS-TP will not resolve
this problem either.
It then remains to be seen which problems these mechanisms do resolve
(compared with per-node MIPs which to me are equivalent to IP address of a
loopback interface of a router).
 
Regards,
     Sasha
  _____  

Subject: RE: [mpls-tp] Lifespan of ingress and egress MIPs: comparison with
802.1ag

Sasha,

 

 
Conclusion: 

 

Further behaviour:

 

General:

 
Regards,
Maarten

  _____  

Luca and all,

 

 
 
My 2c,
     Sasha