Subject: [mpls-tp] MIPs in MPLS-TP

From: Malcolm Betts <[email-masked]>
Date: Wed, 24 Jun 2009 10:21:16 -0400

All,

Since I have received no response from the MEAD team I am now requesting
input from the wider community in particular on the requirement:

MPLS-TP MUST support the capability to determine if a node is a) receiving a
particular LSP on its input port and b) if it is delivering that LSP to the
correct output port without the use of an external (physical) loopback or
relying on an indication from a downstream node.

Regards,

Malcolm Betts

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Malcolm Betts
Sent: June-12-09 12:07 PM
To: [email-masked]
Subject: [mead] MIPs in MPLS-TP

All,

At the recent ITU interim meeting of the questions concerned with MPLS-TP
the issue of the requirement to support two MIPs on a node, one on the input
port and one on the output port was raised.  This was further discussed on a
Q.12/15 conference call.  Below is an extract from those notes.  These notes
have no official status and do not represent the opinion of the ITU.
However, we did think that it would be useful to share our thoughts and get
some early feedback from the MEAD team.

Adrian Farrel suggested that we should try to focus the initial discussion
on the base requirement that motivates the need for two MIPs - I have
provided my personal view of that requirement below:

MPLS-TP MUST support the capability to determine if a node is a) receiving a
particular LSP on its input port and b) if it is delivering that LSP to the
correct output port without the use of an external (physical) loopback or
relying on an indication from a downstream node.

This should allow us to put the MIP discussion in context.

Loa, this is another candidate topic for the MEAD team call next week,
should we raise this issue with the wider MPLS-TP team.....

Regards,

Malcolm Betts

Notes fromQ.12 conference call on the MIP:

3       Summary of the discussion

The problem of describing  a single MIP per node or two MIPs per node one on
the ingress port, a second (optional) MIP on the egress port arises, in
part, from the different approach taken in describing equipment operation in
the IETF and the ITU.

In the MPLS architecture (RFC 3031 and RFC 3032) the processing of MPLS
frames in a node is described in terms of a single abstract interface.  In
this model the node is a single entity and therefore, the ingress and egress
port cannot be distinguished.

In the ITU model the node is decomposed into a number of atomic functions.
Those of interest for this purpose are the input port, fabric and output
port.  This allows the ingress and egress ports to be distinguished.

In MPLS-TP a frame (e.g. an OAM loopback request) is processed within a node
if either the TTL has expired, or, the label identifies that node as the
destination.

In the IETF model an OAM loopback frame targeted to a node will be processed
and looped back by the abstract interface i.e. at some, unspecified, point
within the node.

In the ITU model an OAM loopback frame targeted to a node the loopback
message may contain additional information (e.g. identifier or op code) to
indicate if the loop back is to be performed by the ingress MIP or the
egress MIP.  If the operation is to be performed on the egress MIP then a
full data path check must be been performed. E.g. the request frame should
transit the normal data path within the node and be intercepted by the
egress MIP.

Some participants on the call indicated concern that this ITU description
and behaviour conflicts with the MPLS forwarding behaviour.  They also noted
that the agreement between the IETF and ITU-T is to develop extensions to
the MPLS architecture to support the ITU-T transport requirements in a way
that does not conflict with the current MPLS forwarding model.

3.1     Consequences of not supporting an egress port MIP.

Loopback on ingress port only - thus a FDB corruption in a node will only be
found by a failed loopback on the ingress of the next node downstream.

This is of particular concern if the downstream node is in another operator
domain.  Fault location will be more difficult if the second operator does
not allow the first operator to activate a loopback.  The general conclusion
was that whilst an egress MIP improves the accuracy of fault location it is
possible to operate without this capability. 

3.2     Alternatives to supporting an Egress MIP:

It was suggested that a non-intrusive monitor of CV message on ingress and
egress ports could be used.  It is not clear how this would be accommodated
within the IETF description that only has a single abstract interface.

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Wed, 24 Jun 2009 11:13:20 -0400

Martin,

Your email prompted me to check with our transport experts. Our craft people
do indeed use both ingress monitoring (for LOS, frame error rates, etc.) and
egress loopbacks for fault detection and isolation. So this would be a good
capability to replicate for MPLS-TP. However, if this functionality can be
replicated via a single virtualized MIP in a switch, that¹s OK too. I think
we need a separation of the external functional requirements (ingress
monitoring and egress loopbacks) and how that functionality is instantiated
in a switch.

Cheers,
Andy

On 6/24/09 10:21 , "Malcolm Betts" <[email-masked]> wrote:

> All,
>  
> Since I have received no response from the MEAD team I am now requesting input
> from the wider community in particular on the requirement:
>  
> At the recent ITU interim meeting of the questions concerned with MPLS-TP the
> issue of the requirement to support two MIPs on a node, one on the input port
> and one on the output port was raised. This was further discussed on a Q.12/15
> conference call.  Below is an extract from those notes.  These notes have no
> official status and do not represent the opinion of the ITU.  However, we did
> think that it would be useful to share our thoughts and get some early
> feedback from the MEAD team.
> 
> Adrian Farrel suggested that we should try to focus the initial discussion on
> the base requirement that motivates the need for two MIPs  I have provided my
> personal view of that requirement below:
> 
> Loa, this is another candidate topic for the MEAD team call next week, should
> we raise this issue with the wider MPLS-TP team.....
> 
> Regards,
> 
> Malcolm Betts
> 
> the ingress port, a second (optional) MIP on the egress port arises, in part,
> from the different approach taken in describing equipment operation in the
> IETF and the ITU.
> 
> In the MPLS architecture (RFC 3031 and RFC 3032) the processing of MPLS frames
> in a node is described in terms of a single abstract interface.  In this model
> the node is a single entity and therefore, the ingress and egress port cannot
> be distinguished.
> 
> Those of interest for this purpose are the input port, fabric and output port.
> This allows the ingress and egress ports to be distinguished.
> 
> In the ITU model an OAM loopback frame targeted to a node the loopback message
> may contain additional information (e.g. identifier or op code) to indicate if
> the loop back is to be performed by the ingress MIP or the egress MIP.  If the
> operation is to be performed on the egress MIP then a full data path check
> must be been performed. E.g. the request frame should transit the normal data
> path within the node and be intercepted by the egress MIP.
> 
> Some participants on the call indicated concern that this ITU description and
> behaviour conflicts with the MPLS forwarding behaviour.  They also noted that
> the agreement between the IETF and ITU-T is to develop extensions to the MPLS
> architecture to support the ITU-T transport requirements in a way that does
> not conflict with the current MPLS forwarding model.
> 
> Loopback on ingress port only  thus a FDB corruption in a node will only be
> domain.  Fault location will be more difficult if the second operator does not
> allow the first operator to activate a loopback.  The general conclusion was
> that whilst an egress MIP improves the accuracy of fault location it is

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Wed, 24 Jun 2009 11:20:20 -0400

That¹s what happens when you answer an email too quickly  I meant
³Malcolm², not ³Martin², of course! My apologies.

Cheers,
Andy

On 6/24/09 11:13 , "Malis, Andrew G. (Andy)"
<[email-masked]> wrote:

> replicated via a single virtualized MIP in a switch, that¹s OK too. I think we
> need a separation of the external functional requirements (ingress monitoring
> and egress loopbacks) and how that functionality is instantiated in a switch.
> 
> Cheers,
> Andy
> 
>> and one on the output port was raised. This was further discussed on a
>> the base requirement that motivates the need for two MIPs  I have provided
>> my personal view of that requirement below:
>> 
>> indicate if the loop back is to be performed by the ingress MIP or the egress
>> MIP.  If the operation is to be performed on the egress MIP then a full data
>> path check must be been performed. E.g. the request frame should transit the
>> normal data path within the node and be intercepted by the egress MIP.
>> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 24 Jun 2009 17:23:17 +0200

Andy,

Thanks for the very important information. 

Can you please elaborate on what you call "virtualized MIP" in term of
functionally required? 

Best regards,

Nurit

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Malis, Andrew G. (Andy)
Sent: Wednesday, June 24, 2009 6:13 PM
To: Malcolm Betts; MPLS-TP ad hoc; [email-masked]
Cc: Q12/15 ITU (MLIST)
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Martin,

Your email prompted me to check with our transport experts. Our craft
people do indeed use both ingress monitoring (for LOS, frame error
rates, etc.) and egress loopbacks for fault detection and isolation. So
this would be a good capability to replicate for MPLS-TP. However, if
this functionality can be replicated via a single virtualized MIP in a
switch, that's OK too. I think we need a separation of the external
functional requirements (ingress monitoring and egress loopbacks) and
how that functionality is instantiated in a switch.

Cheers,
Andy

All,

MPLS-TP MUST support the capability to determine if a node is a)
receiving a particular LSP on its input port and b) if it is delivering
that LSP to the correct output port without the use of an external
(physical) loopback or relying on an indication from a downstream node.

Regards,
 
Malcolm Betts

All,

At the recent ITU interim meeting of the questions concerned with
MPLS-TP the issue of the requirement to support two MIPs on a node, one
on the input port and one on the output port was raised. This was
further discussed on a Q.12/15 conference call. Below is an extract from
those notes.  These notes have no official status and do not represent
the opinion of the ITU.  However, we did think that it would be useful
to share our thoughts and get some early feedback from the MEAD team.

Adrian Farrel suggested that we should try to focus the initial
discussion on the base requirement that motivates the need for two MIPs
- I have provided my personal view of that requirement below:

MPLS-TP MUST support the capability to determine if a node is a)
receiving a particular LSP on its input port and b) if it is delivering
that LSP to the correct output port without the use of an external
(physical) loopback or relying on an indication from a downstream node.

Regards,

Malcolm Betts

The problem of describing  a single MIP per node or two MIPs per node
one on the ingress port, a second (optional) MIP on the egress port
arises, in part, from the different approach taken in describing
equipment operation in the IETF and the ITU.

In the MPLS architecture (RFC 3031 and RFC 3032) the processing of MPLS
frames in a node is described in terms of a single abstract interface.
In this model the node is a single entity and therefore, the ingress and
egress port cannot be distinguished.

In the ITU model the node is decomposed into a number of atomic
functions.  Those of interest for this purpose are the input port,
fabric and output port.  This allows the ingress and egress ports to be
distinguished.

In MPLS-TP a frame (e.g. an OAM loopback request) is processed within a
node if either the TTL has expired, or, the label identifies that node
as the destination.

In the IETF model an OAM loopback frame targeted to a node will be
processed and looped back by the abstract interface i.e. at some,
unspecified, point within the node.

In the ITU model an OAM loopback frame targeted to a node the loopback
message may contain additional information (e.g. identifier or op code)
to indicate if the loop back is to be performed by the ingress MIP or
the egress MIP.  If the operation is to be performed on the egress MIP
then a full data path check must be been performed. E.g. the request
frame should transit the normal data path within the node and be
intercepted by the egress MIP.

Some participants on the call indicated concern that this ITU
description and behaviour conflicts with the MPLS forwarding behaviour.
They also noted that the agreement between the IETF and ITU-T is to
develop extensions to the MPLS architecture to support the ITU-T
transport requirements in a way that does not conflict with the current
MPLS forwarding model.

Loopback on ingress port only - thus a FDB corruption in a node will
only be found by a failed loopback on the ingress of the next node
downstream.

This is of particular concern if the downstream node is in another
operator domain.  Fault location will be more difficult if the second
operator does not allow the first operator to activate a loopback.  The
general conclusion was that whilst an egress MIP improves the accuracy
of fault location it is possible to operate without this capability. 

It was suggested that a non-intrusive monitor of CV message on ingress
and egress ports could be used.  It is not clear how this would be
accommodated within the IETF description that only has a single abstract
interface.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Jun 2009 17:35:54 +0100

Malcolm Betts wrote:
>
> All,
>
>  
>
> Since I have received no response from the MEAD team I am now 
> requesting input from the wider community in particular on the 
> requirement:
>
>  
>
> receiving a particular LSP on its input port
>
This is straightforward and I can see no issue with it.

> and b) if it is delivering that LSP to the correct output port without 
> the use of an external (physical) loopback or relying on an indication 
> from a downstream node.
>

To do this experimentally (as in loopback) is difficult and I think 
would in general require new hardware.
To do it by inspection of the internal state is tractable, but tells you 
less about the true internal state
of for example the hardware.

For example consider a design that does ingress forwarding or central 
forwarding. This would require
a packet inspection stage to be added to the egress packet processor 
(which is by definition
optimized out of an ingress or central forwarding system), or it would 
require a loopback on the
egress. However a loopback will sent the packet back to the looping LSR 
with the MAC address
and label stack of the next hop which will then be rejected by the LSR 
performing the loopback.

Stewart

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 19:28:28 +0100

An observation:
 
A connection (which has a very specific meaning in order to be able to
manage resource, key of which is that a connection can only have a
single source) should only appear on a single ingress port of any
transit node in a network.  It might have one or more egress ports on a
transit node, ie if a p2p or p2mp connection respectively.  If one is
verifying correct connectivity then one needs to check:
-    LSP/connection entering on single/correct ingress port
-    LSP/connection leaving on correct egress port(s)
 
This is subtly different to verifying correct connectivity only, ie one
should also check that there is no unintended replication out of
incorrect ports.
 
IMO this can be done on-demand by checking an end-end CV OAM flow in/out
of a node.  And it really needs to be done unidirectionally to cater for
p2p and p2mp cases (noting in addition that request/response OAM
messages cannot be relied on in co-Xs mode networks to correctly trace
unintended replication/misbranching defects, ie leaking traffic is
unlikely to have a return path).
 
regards, Neil 

	From: Malcolm Betts [mailto:[email-masked]] 
	Sent: 24 June 2009 15:21
	To: MPLS-TP ad hoc; [email-masked]
	Cc: Q12/15 ITU (MLIST)
	Subject: [T15Q12] MIPs in MPLS-TP

	All,

	Regards,

	Malcolm Betts

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Malcolm Betts
	Sent: June-12-09 12:07 PM
	To: [email-masked]
	Subject: [mead] MIPs in MPLS-TP

	All,

	At the recent ITU interim meeting of the questions concerned
with MPLS-TP the issue of the requirement to support two MIPs on a node,
one on the input port and one on the output port was raised.  This was
further discussed on a Q.12/15 conference call.  Below is an extract
from those notes.  These notes have no official status and do not
represent the opinion of the ITU.  However, we did think that it would
be useful to share our thoughts and get some early feedback from the
MEAD team.

	Loa, this is another candidate topic for the MEAD team call next
week, should we raise this issue with the wider MPLS-TP team.....

	Regards,

	Malcolm Betts

	The problem of describing  a single MIP per node or two MIPs per
node one on the ingress port, a second (optional) MIP on the egress port
arises, in part, from the different approach taken in describing
equipment operation in the IETF and the ITU.

	In the MPLS architecture (RFC 3031 and RFC 3032) the processing
of MPLS frames in a node is described in terms of a single abstract
interface.  In this model the node is a single entity and therefore, the
ingress and egress port cannot be distinguished.

	In MPLS-TP a frame (e.g. an OAM loopback request) is processed
within a node if either the TTL has expired, or, the label identifies
that node as the destination.

	In the IETF model an OAM loopback frame targeted to a node will
be processed and looped back by the abstract interface i.e. at some,
unspecified, point within the node.

	In the ITU model an OAM loopback frame targeted to a node the
loopback message may contain additional information (e.g. identifier or
op code) to indicate if the loop back is to be performed by the ingress
MIP or the egress MIP.  If the operation is to be performed on the
egress MIP then a full data path check must be been performed. E.g. the
request frame should transit the normal data path within the node and be
intercepted by the egress MIP.

	Loopback on ingress port only - thus a FDB corruption in a node
will only be found by a failed loopback on the ingress of the next node
downstream.

	This is of particular concern if the downstream node is in
another operator domain.  Fault location will be more difficult if the
second operator does not allow the first operator to activate a
loopback.  The general conclusion was that whilst an egress MIP improves
the accuracy of fault location it is possible to operate without this
capability. 

	It was suggested that a non-intrusive monitor of CV message on
ingress and egress ports could be used.  It is not clear how this would
be accommodated within the IETF description that only has a single
abstract interface.

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Wed, 24 Jun 2009 11:26:22 -0400

Nurit,

I was just trying to separate the functionality from whether it would
require one or two MIPs in a switch to be modeled or implemented. I really
don¹t have anything anything more concrete than that.

Cheers,
Andy

On 6/24/09 11:23 , "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
<[email-masked]> wrote:

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Malis, Andrew G. (Andy)

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 25 Jun 2009 11:38:55 +0300

Stewart, Malcolm and all,
This may be naive, but:

IF
Each NE traversed by an LSP can report that it receives (OAM messages for) this LSR via a specific ingress port (the first half of the requirement)
AND

(b) The connectivity between egress ports of the upstream NE to ingress ports of the downstream NE is known (probably required in any case0
would it not be enough just to check that OAM messages for a specific LSP are received on specific ingress ports by all the NEs traversed by the LSP?

Regards,
     Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Wednesday, June 24, 2009 7:36 PM
To: Malcolm Betts
Cc: MPLS-TP ad hoc; Q12/15 ITU (MLIST); [email-masked]
Subject: Re: [mpls-tp] MIPs in MPLS-TP

Malcolm Betts wrote:
All,
Since I have received no response from the MEAD team I am now requesting input from the wider community in particular on the requirement:

MPLS-TP MUST support the capability to determine if a node is a) receiving a particular LSP on its input port

and b) if it is delivering that LSP to the correct output port without the use of an external (physical) loopback or relying on an indication from a downstream node.

To do this experimentally (as in loopback) is difficult and I think would in general require new hardware.
To do it by inspection of the internal state is tractable, but tells you less about the true internal state
of for example the hardware.

For example consider a design that does ingress forwarding or central forwarding. This would require
a packet inspection stage to be added to the egress packet processor (which is by definition
optimized out of an ingress or central forwarding system), or it would require a loopback on the
egress. However a loopback will sent the packet back to the looping LSR with the MAC address
and label stack of the next hop which will then be rejected by the LSR performing the loopback.

Stewart