Re: [mpls-tp] Alarm Reporting (aka AIS)

[Alexander Vainshtein <[e-mail]>]

Maarten,
Lots of thanks for a proposing a very creative solution to the problem.

The down side of your proposal is that it requires somebody to insert context labels where none are used today (and indeed, none are required) - just for the sake of being able to insert the AIS correctly.

Please note also that 5331 only applies to upstream allocated labels, and there are certain restrictions associated with their usage. As a minimum, they require a different Ethertype (or Protocol number).

Do you imply that MPLS-TP must only use upstream-allocated labels?

Regards,
     Sasha










From: maarten vissers [[e-mail]]
Sent: Friday, December 10, 2010 3:15 PM
To: Alexander Vainshtein
Cc: [e-mail]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)


Sasha,

LSP-AIS is to be inserted under signal fail conditions when the LSP does not terminate and the LSP label is swapped from A  to B. LSP-AIS is to be inserted with this registered label value B.

PW-AIS is to be inserted under signal fail conditions when the PW does not terminate and the PW label is swapped from C  to D. PW-AIS is to be inserted with this registered label value D.

When a LSP label is popped, the next function is an LSP MEP. For this case it is not necessary to insert the LSP-AIS packet as it would be terminated immediately in that LSP MEP; instead the server signal fail condition is forwarded from the adaptation sink to the MEP sink via the SSF signal. It is equipment specific how this SSF is implemented.

When a PW label is popped, the next function is a PW MEP. For this case it is not necessary to insert the PW-AIS packet as it would be terminated immediately in that PW MEP; instead the server signal fail condition is forwarded from the adaptation sink to the MEP sink via the SSF signal. It is equipment specific how this SSF is implemented.

When an LSP is terminated, its LSP MEP will be able to detect if there is a SF condition. For such case, the client LSP and/or PW and/or VLAN signals passing through this LSP MEP have LSP/PW labels that will be swapped. For the case of client VLANs (i.e. HVPLS), ETH-AIS for each of those VLANs is to be inserted. For the case of client LSPs or PWs, client LSP-AIS or PW-AIS should be inserted. As this will be a subset of the LSP, PW and/or VLAN signals passed through an input port, I understand from your email that today’s MPLS NNI port designs do not have the ability to identify such subsets. Correct? Such subsets of LSPs, PWs and/or VLANs are missing their context information. This can be resolved by using context-specific label spaces, which I find defined in RFC5331.

   An example of such a context is a tunnel over which MPLS packets on
   LSP1 may be received.  In this case, the top label of the MPLS
   packet, after tunnel decapsulation, is looked up in a label space
   that is specific to the root of the tunnel.  This does imply that Lr
   be able to determine the tunnel over which the packet was received.
   Therefore, if the tunnel is an MPLS tunnel, penultimate-hop-popping
   (PHP) MUST be disabled for the tunnel.

I.e. A transport-LSP is a tunnel over which MPLS-TP LSP, PW and VLAN packets may be received. Use of a context-specific label space seems the appropriate existing MPLS compliant mechanism to be used. Such context specific label space can be much smaller than 1M, such that there will be no scalability issue.

Regards,
Maarten



From: Alexander Vainshtein [mailto:[e-mail]] 
Sent: 9 December 2010 11:05
To: Maarten Vissers
Cc: [e-mail]; [e-mail]
Subject: RE: [mpls-tp] Alarm Reporting (aka AIS)

Maarten,
One brief comment that you probably have heard quite a few times from me.

You have said in your response to Andy Reid:
The adaptation sink functions in the transport network technologies not only “can know” this information, they actually “do know” this information.
The problem with MPLS-TP is that, as long as its data plane is aligned with that of MPLS (and it is!) its analog of the “adaptation sink function”, namely the ILM entry with the “Pop and Loop” action on a specific label do not have this information. I.e., when MPLS pops a label, it can handle both labeled and unlabeled packets that result from this action. When the resulting packet is labeled, handling of the next label does not depend on the previous one. 
And of course handling unlabeled packets (IP as an immediate client of an MPLS-TP LSP) is just as possible and, IMHO, just as relevant…

After writing this, I think (and I apologize that I’ve only noticed it that late), that IP as an MPLS-TP client that does not have any AIS is a great counter-example to AIS into the clients…

Regards,
     Sasha