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

From: maarten vissers <[email-masked]>
Date: Fri, 10 Dec 2010 13:15:03 +0000

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:[email-masked]]
Sent: 9 December 2010 11:05
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 11 Dec 2010 21:11:09 +0200

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 [[email-masked]]
Sent: Friday, December 10, 2010 3:15 PM
To: Alexander Vainshtein
Cc: [email-masked]
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)

Sasha,

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.

Regards,
Maarten

Maarten,

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

---

From: maarten vissers <[email-masked]>
Date: Mon, 13 Dec 2010 09:52:27 +0000

Sasha,

It is not only AIS (including the LDI flag) that needs this context information. LKR is the other maintenance signal that requires it. See draft-ietf-mpls-tp-fault-03.txt.

-----

The text in section 3 of RFC5331 lists a couple of context-specific 
label space examples and ends with the following notion:

   There may be other sorts of contexts as well.  For instance, we
   define the notion of an MPLS label being used to establish a context,
   i.e., identify a label space.  A "context label" is one that
   identifies a label table in which the label immediately below the
   context label should be looked up.

RFC 5331 is as such open to other context-specific label spaces.

An example of such other context-specific label space is a MPLS-TP
Section and a MPLS-TP transport-LSP. Other examples could be Working 
and Protection SPME-LSPs. 

As RFC 5331 (August 2008) has been developed prior to MPLS-TP OAM, 
this OAM application of context-specific label spaces is not included; 
it will have to be included in one of the MPLS-TP RFCs; e.g. in 
draft-ietf-mpls-tp-fault-03.txt as the mechanisms in this draft 
require this context-specific label space information.

Such MPLS-TP Section and transport-LSP context-specific label spaces 
do not need to use upstream-allocated labels. P2P Sections and P2P 
transport-LSPs can use context-specific label spaces with 
downstream-allocated labels. P2MP transport-LSPs must use 
context-specific label spaces with upstream-allocated labels.

Regards,
Maarten

> -----Original Message-----
> Sent: 11 December 2010 20:11
> To: maarten vissers
> Cc: [email-masked]
> 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).
> 
> 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.
> 
> 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
> 
> 
> 
> 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