Subject: [mpls-tp] Per-platform vs. per interface label sapce for MPLS TP (was: AIS/FDI( (was: Associated bidirectional transport path requirements))

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 29 May 2009 22:20:26 +0300

Nurit hi,
IMHO and FWIW there are several points that should be taken into account when it comes to per-interface label space:

 1.
I believe (Loa and others who have been there when MPLS was born can, of course, correct me) that per-interface label space has been mainly invented to support label-controlled ATM interfaces (since the VPI and VCI as labels are a scarce resource). This may or may not be important today, but is worth keeping in mind.
 2.
RFC 3031 is quite specific regarding what represents an interface when it comes to per-interface label spaces as can be seen from Section 3.2. To the best of my understanding, restrictions on usage of per-interface label spaces there do not sit well with treating terminated tunnel LSPs as interfaces when it comes to per-interface label spaces
 3.
As mentioned already, PWE3 mandates usage of per-platform label space for PW labels (see RFC 4447, Section 3). So if MPLS-TP cannot coexist with per-platform label space, it cannot coexist with PWE3 either. And this, in its turn, would mean that MPLS-TP requires some new mechanisms in order to carry any payload (which, presumably, is an ultimate purpose of any transport technology).
 4.
AFAIK, MPLS (unicast) does not impose any limitations on interworking between devices using per-platform and per-interface label spaces - because labels in unicast MPLS are allocated and bound to FECs by downstream routers and distributed upstream. This seems to be the fundamental assumption of 3031, and it does not preclude using an OSS as the distributor. But it is not clear to me whether MPLS-TP intends to preserve this fundamental assumption, or it is going to treat LSRs as "dumb switches" that know how to swap an incoming label to an outgoing one, but do not care about the purpose (FEC) which is achieved by such swapping.

Regards,
     Sasha
________________________________
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [[email-masked]]
Sent: Thursday, May 28, 2009 4:08 PM
To: Alexander Vainshtein; Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

Hi Sasha,

I would like to refer you to draft-martinotti-mpls-tp-interworking-01.txt which addresses

the interworking scenarios between MPLS-TP and MPLS.

Do you see any scenario in which there may be an issue

as a result of using per-i/f label space in MPLS-TP?

Best regards,

Nurit

P.S. as the MPLS protocol allows both per-platform and per-interface label spaces for

LSPs and does not mandate both (for LSP case), an implementation may support per

interface only for LSPs. How do you guarantee interoperability between MPLS NEs

that one supports per-i/f and one supports per-platform? How MPLS handles this case?
I think that at least for MPLS-TE the per-i/f case is very popular.
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Alexander Vainshtein
Sent: Thursday, May 28, 2009 8:27 AM
To: Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

Juergen,
Lots of thanks for a detailed response, and my apologies for late reaction.

Just a few short comments:

 1.  RFC 3031 does not make it clear if a server layer LSP could be considered an "interface" with a separate per-interface label space. But taking into account unlimited depth of label stacking in MPLS, this would hardly be feasible as the number of "label spaces" a LER has to maintain would grow exponentially.
 2.  AFAIK, per-platform label space is highly popular in MPLS and (as noted earlier on this list), its usage is MANDATED for PW labels.
 3.  IMHO and FWIW, ability of MPLS-TP to coexist with per-platform label space is one of the key unresolved issues of the MPLS-TP project, because it would mean lack of backward compatibility with the already deployed equipment.

Regards,

     Sasha

________________________________
From: Heiles, Juergen (NSN - DE/Munich) [[email-masked]]
Sent: Tuesday, May 26, 2009 12:50 PM
To: Alexander Vainshtein
Cc: [email-masked]; George Newsome; ext Ben Niven-Jenkins; [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)
Hi Sasha,

see my comments below.

Regards

Juergen

________________________________
From: ext Alexander Vainshtein [mailto:[email-masked]]
Sent: Saturday, May 16, 2009 8:59 AM
To: Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]; George Newsome; ext Ben Niven-Jenkins; [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)
Juergen,

You've presented a very clear-cut analysis of the mixed implicit requirements which are addressed by AIS in TDM-based networks.

You've also demonstrated that some of these requirements are not applicable to packet-based networks restricting potential usefulness of AIS to a single use case - an "alarm correlation helper" in the hierarchy of MPLS-TP layers.

The point that remains yet unclear to me is, can this use case be addressed within the framework of MPLS data plane architecture?

To the best of my understanding, in order to achieve the required functionality, the termination point of a lower-layer LSP in MPLS-TP MUST be aware of each individual client LSP.

[JH] Yes, or the other way the client adaptation has to be aware over which server layer trail the client was transported.

Please note that such awareness was not required in TDM networks, since it was possible to spread the AIS pattern ("all ones") across all potential clients.
[JH] This is not really true as the (PDH) AIS pattern also has to be with the correct bit rate which is client specific. In SDH the AU/TU AIS in the pointer takes care of the timing, but as the pointer is not passed thru the buffer you have to know the AU/TU structure. A TDM network element is always aware about the client signals transported in a server layer trail (implicitly or by configuration).

 This kind of behavior is clearly not applicable to MPLS-TP.

In the case of ATM, awareness of the server layer (VPC) termination point of every specific client (VCC) is an integral part of the data plane since VPI values have only meaning within the scope defined by the containing VPC. In other words, regardless of the AIS, the server layer had to be aware of each specific client since otherwise traffic could not be forwarded correctly. AIS propagation in this case was more complicated than in the TDM case, but still free.

On the other hand the MPLS data plane architecture as described in RFC 3031 (Section 3.14) recognizes just two types of label scope:

 *   Per-platform
 *   Per interface.

And it also defines (in Sections 3.10, 3.11 and 3.13) that forwarding is done by looking up the label at the top of the label stack. (Multiple label look-ups, regardless of implementation, mean popping the top label and forwarding the still labeled packet to the "loopback interface").

IMHO and FWIW this means that MPLS data plane does not, per se, require the server termination point awareness of each and every specific client within the terminated server LSP.

Hence MPLS-TP actually presents two choices:

 1.  Explicitly require such an awareness. This would enable (among other things) AIS but would be probably costly in the terms of look-ups
 2.  Preserve existing flexibility of the MPLS data plane, and drop the AIS-related requirement.

Did I miss something?
[JH]  If per platform label space means that the label can be from any interface (=server layer trail) and the network element doesn't know from which interface it comes, yes we have a problem. However it is a more general problem. If can for example result in unintended merging if the same label is received via more than one interface due to a configuration error or a problem in an upstream LSR.

Regards

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Heiles, Juergen (NSN - DE/Munich) [[email-masked]]
Sent: Friday, May 15, 2009 3:08 PM
To: ext Ben Niven-Jenkins; George Newsome; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was     Associatedbidirectionaltransportpathrequirements)

Hi colleagues,

I have been quiet for a long time, but now I think I have to add my 2
cents to this discussion.

Different purposes of the AIS signal are mixed in the discussion.
1. In a TDM circuit switched network the resources for a certain
connection (the time slots) are fixed assigned and have to be filled
even if the connection is interrupted due to an upstream server layer
failure. This replacement signal has to fulfill certain criteria like
for timing in order to prevent strange behavior and failure conditions
downstream like buffer overflow/underflow. One may generate a random
pattern or just send what is in the buffer. Such patterns however may
result in some strange defect detections downstream (at non-intrusive
monitors or path termination) which could have a negative impact on
protection switching. Therefore it makes sense to generate a well
defined replacement signal.
-> AIS purpose: a well behaving signal to prevent strange and unwanted
behaviors downstream of the failure with the layer network

2. One transport network paradigm is to have layer networks decoupled so
that each layer network can be operated on its own. When we move to the
physical layers or close to them this is however no longer 100%
fulfilled. The SDH Regenerator section depends on the clock from the
Multiplex section (the same applies for OTU and ODU). If a MS fails a
replacement at least of the clock is required in order to have a correct
behavior at the downstream RS and other server layers. The Optical and
electrical layer require a certain pattern from their digital client
layers like RS or OTU in order to work correctly
-> AIS purpose: ensure correct operation of downstream server layers in
cases where server and client layers are not 100% decoupled (this is the
example from George).

3. A failure of a server layer connection may effect a large number of
client layer connections that are transported via this connection.
These client layer connections are terminated and monitored at network
elements that are far way from the actual failure location. They might
be even in a different management or operator domain. Without AIS all of
them would raise a primary failure alarm (loss of connectivity). While a
network element can differentiate between local and remote failures
based on local information, it cannot differentiate between a failure at
the monitored layer network or some server layer networks upstream. With
AIS it is possible.
-> AIS purpose: alarm correlation to prevent alarm storms and
differentiate between failures at the layer network and at server layer
networks.

As a side effect, AIS detection is often much faster as loss of
connectivity detection (e.g. SDH VC-4 TTI mismatch vs. AU-AIS detection)
and can trigger protection switching therefore faster. So this might not
be the case for MPLS-TP depending on the specific methods that will be
used.

For MPLS-TP item 1 doesn't apply as it is a packet layer network which
doesn't require that packets are constantly sent for a certain
connection.
Item 2 does also not apply as the MPLS-TP layer network is decoupled
from other layer networks concerning its operation (I assume so;-).
This leaves us with item 3 which applies to any kind of transport
network technology. So it is not a must have I see it as very useful.
Some operators might not be interested in it at all or do alarm
correlation in the network management. Still they can do that. They have
to enable AIS alarm reporting and treat AIS alarms in the same way as
loss of connectivity alarms.

Regards

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of ext Ben Niven-Jenkins
>Sent: Friday, May 08, 2009 8:54 PM
>To: George Newsome; [email-masked]
>Cc: [email-masked]
>Subject: Re: [mpls-tp] AIS/FDI (was
>Associatedbidirectionaltransportpathrequirements)
>
>George,
>
>On 08/05/2009 18:05, "George Newsome" <[email-masked]> wrote:
>> Huub van Helvoort wrote:
>>> In MPLS-TP the CC provides the conductivity.
>>> If a server layer fails, there are no packets transited, including
>>> the CC, so isn't there a need to show conductivity?
>>>
>> The servers that mpls-tp is to run on already provide
>monitoring, and it
>> is that OAM which shows the server conductivity. mpls-tp will not run
>> natively over a fiber, so does not need to carry its own baggage for
>> server conductivity checking.
>
>This is a key point IMO. A piece of MPLS-TP equipment can
>determine whether
>a failure is local/remote by correlating information acquired from the
>various layer networks which terminate on it. It doesn't need
>to have all
>the information it requires be present in the MPLS-TP layer network.
>
>Ben
>
>_______________________________________________
>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