Subject: [mpls] Up and Down MEPs in RFC 6371

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jan 2012 14:55:03 +0200

Dave, Italo and all,

I have a couple of questions regarding the definition of Up and Down MRPs in RFC 6371<http://datatracker.ietf.org/doc/rfc6371/?include_text=1>.
The problematic text states:

   A node hosting a MEP can either support per-node MEP or per-interface
   MEP(s).  A per-node MEP resides in an unspecified location within the
   node, while a per-interface MEP resides on a specific side of the
   forwarding engine.  In particular, a per-interface MEP is called an
   "Up MEP" or a "Down MEP" depending on its location relative to the
   forwarding engine.  An "Up MEP" transmits OAM packets towards, and
   receives them from, the direction of the forwarding engine, while a
   "Down MEP" receives OAM packets from, and transmits them towards, the
   direction of a server layer.

Here are my questions:

1.  The text seems to suggest that there are three types of MEPs: per-node (neither Up nor Down), per-interface Up and per-interface Down. Is this understanding correct?

2.  Which types of MEPs can be encountered in an MPLS-TP Section considered as a Maintenance Entity (ME)?

a.  The text in section 2.2 states: "This document uses the term 'Section' exclusively to refer to the n=0 case of the term 'Section' defined in RFC 5960"

b.  The text in Section 3.3 states: "Any MPLS-TP LSR can implement a MEP for an MPLS-TP Section"

c.  My guess (FWIW) is that only Down MEPs can be associated with the MPLS-TP section. Is this guess correct?

3.  Which type of MEPs can be encountered in a P2P MPLS-TP LSP (or MS-PW) considered as an ME?

a.  The text in Section 3.3 states: "In the context of an MPLS-TP LSP, only LERs can implement MEPs"

b.  The text mentions (e.g., in Section 6.4) that OAM flows must be fate-sharing with the data packets for the corresponding ME

c.  My guess (FWIW) is that LERs (and T-PEs) can only implement per-node or per-interface Down MEPs. Is this guess correct? If not, what did I miss?

4.  Can you describe a case when a per-interface Up Source MEP can be encountered for one of the MEs that MPLS-TP deals with (i.e., Section, LSP or PW) and explain how fate-sharing with the data packets is provided in such a case? My guess (FWIW) is that this is impossible without some changes in the MPLS-TP data plane as defined in RFC 3031<http://datatracker.ietf.org/doc/rfc3031/?include_text=1> and RFC 5960<http://datatracker.ietf.org/doc/rfc5960/?include_text=1>. Is this guess correct? If not could you please explain how it is supposed to operate in the terms of RFC 3031 (NHLFE, FTN and/or ILM)?

5.  The diagrams in Figure 3of the RFC seem to suggest that, in the case of per-interface MEPs, Source and Sink MEP are always either both Up or both Down.

a.  Is this understanding correct? If not, could you please present some examples to the contrary?

b.  If my understanding in (a) above is correct and if, as mentioned in (4) above, per-interface Up MEPs cannot be implemented in MPLS-TP, this would imply that per-interface Up Sink MEPs are useless. Did I miss something?

Regards, and lots of thanks in advance,
     Sasha

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jan 2012 15:03:26 +0200

Dave, Italo and all,
An additional question:

Is there any relationship between per-node vs. per-interface MEPs and per-platform vs. per-interface label spaces?
If yes, does it mean that only per-node MEPs can be encountered in the case of PWs?

Regards, and, again, lots of thanks in advance,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Stewart Bryant ([email-masked])
Subject: [mpls] Up and Down MEPs in RFC 6371

Dave, Italo and all,

Here are my questions:

---

From: David Allan I <[email-masked]>
Date: Wed, 11 Jan 2012 11:29:00 -0500

HI Sasha:

Good question!

I'm not aware of any explicit relationship, nor can I envision the need for specifying one.

Given MPLS-TP is restricted to connections, implying a single interface of arrival for an LSP, it scopes even a per-platform label to being of only per-interface significance, but there should be no issue there, it is purely an implementation choice.

If I take a more general view, and apply the concept of per-interface MEPs across the MPLS architecture (e.g. MP2P), then with per platform labels, I simply have multiple MEPs that have a common label of arrival on different interfaces for a given LSP.

So that is my first blush,

cheers
Dave

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, January 11, 2012 5:03 AM
To: David Allan I; [email-masked]
Cc: [email-masked]; Stewart Bryant ([email-masked])
Subject: RE: Up and Down MEPs in RFC 6371

Dave, Italo and all,
An additional question:

Dave, Italo and all,

Here are my questions:

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jan 2012 18:37:36 +0200

Dave,
Lots of thanks for a prompt response!

I am not sure I can agree with your statement "MPLS-TP is restricted to connections, implying a single interface of arrival for an LSP".
Please consider the case when an LSP of interest (or a PW) is nested in a protected "tunnel" that is comprised of, say, active and standby LSPs.
I would expect these LSPs to be as disjoint as possible including the "last mile" interfaces on the tail-end LER.
If this is the case, I would say that binding a MEP on the nested LSP/PW to a specific interface would be impossible. Or do I miss something?

What do you think?

Regards,
     Sasha

From: David Allan I [mailto:[email-masked]]
Sent: Wednesday, January 11, 2012 6:29 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]; Stewart Bryant ([email-masked])
Subject: RE: Up and Down MEPs in RFC 6371

HI Sasha:

Good question!

cheers
Dave

Dave, Italo and all,

Here are my questions:

---

From: <[email-masked]>
Date: Wed, 11 Jan 2012 16:50:14 +0000

Hi Sasha,  Please excuse for jumping in.....

A connection has a very specific construct meaning, ie it can only have a single source.  Indeed, this is whole basis of the 3 labelling short-cuts (==information removal) that can be applied to the co-ps mode traffic units:
-        remove SA label
-        no need for PID label (if single client over server connection life)
-        forwarding label (==DA proxy) only need be link-unique (amongst all potential clients sharing that link)

None of these labelling short-cuts can be applied to the cl-ps mode traffic units.....simply because it is not based on a parent connection that 'steers/constrains' the child traffic units.

Not sure how well this is appreciated by all, eg I have seen some fairly senior IETF folks swear a PW label is a scaling/muxing label when in practice it must be SA label proxy if there is any server merging...as indeed there is in the LDP spin of MPLS.  Of course, one cannot also truly manage resource when one does not have connections either.

This is why must MPLS-TP is restricted to connections.

Note also in the case you are suggesting the 'working' and 'protection' entities are 2 different connections.  And yes maximal disjointedness between them is a key goal...noting carefully that the lowest layer network graph (usually a duct layer) determines the maximum practical disjoint connectivity, ie all client layers cannot have a greater disjointed connectivity than the duct layer.

regards, Neil

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 11 January 2012 16:38
To: David Allan I
Cc: [email-masked]; [email-masked]; Stewart Bryant ([email-masked])
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

Dave,

What do you think?

Regards,
     Sasha

HI Sasha:

Good question!

cheers
Dave

Dave, Italo and all,

Here are my questions:

---

From: David Allan I <[email-masked]>
Date: Wed, 11 Jan 2012 11:55:49 -0500

Perfect, good example of UP MEP for a common label appearing on multiple interfaces in a TP environment...

The implication vis-a-vis using per-interface labels on a protected path is the protected path is an interface. I am not aware of a mechanism to assign a label space to a specific LSP although others may correct me. So it is per-platform labels, and regardless of per interface or per platform, an UP MEP distributed across multiple interfaces implying coordination of state.

As most implementations would also put a per node MEP on an ingress card, I'm not sure there is a practical difference...

thanks
Dave

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, January 11, 2012 8:38 AM
To: David Allan I
Cc: [email-masked]; Stewart Bryant ([email-masked]); [email-masked]
Subject: RE: Up and Down MEPs in RFC 6371

Dave,

What do you think?

Regards,
     Sasha

HI Sasha:

Good question!

cheers
Dave

Dave, Italo and all,

Here are my questions:

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Jan 2012 20:01:00 +0200

Dave,
Lots of thanks for a prompt response.

One brief comment and one question:

 1.  To the best of my understanding per-LSP label space would explicitly contradict RFC 3031.
 2.  I do not understand why you're speaking about an Up MEP in this case. Could you please explain?

Regards,
     Sasha

________________________________
From: David Allan I [[email-masked]]
Sent: Wednesday, January 11, 2012 6:55 PM
To: Alexander Vainshtein
Cc: [email-masked]; Stewart Bryant ([email-masked]); [email-masked]
Subject: RE: Up and Down MEPs in RFC 6371

thanks
Dave

Dave,

I am not sure I can agree with your statement “MPLS-TP is restricted to connections, implying a single interface of arrival for an LSP”.
Please consider the case when an LSP of interest (or a PW) is nested in a protected “tunnel” that is comprised of, say, active and standby LSPs.
I would expect these LSPs to be as disjoint as possible including the “last mile” interfaces on the tail-end LER.
If this is the case, I would say that binding a MEP on the nested LSP/PW to a specific interface would be impossible. Or do I miss something?

What do you think?

Regards,
     Sasha

HI Sasha:

Good question!

cheers
Dave

Dave, Italo and all,

Here are my questions:

a.  The text in section 2.2 states: “This document uses the term 'Section' exclusively to refer to the n=0 case of the term 'Section' defined in RFC 5960”

b.  The text in Section 3.3 states: “Any MPLS-TP LSR can implement a MEP for an MPLS-TP Section”

a.  The text in Section 3.3 states: “In the context of an MPLS-TP LSP, only LERs can implement MEPs”

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Jan 2012 14:57:49 -0500

Dear Sasha, et al.,
would offer my $.02.
Couple somewhat generic comments:

 *
in most cases, nodal MEP is identical to Down MEP
 *
ME that is terminated by Up MEPs is different from ME terminated by Down MEPs over the same LSP/PW
 *
ME can be terminated by MEP of the same class, i.e. nodal, Up or Down
 *
I don't know how practical are Up MEPs for MPLS-TP

 More notes are in-line and tagged GIM>>.

    Regards,
        Greg

Dave, Italo and all,
An additional question:

Is there any relationship between per-node vs. per-interface MEPs and per-platform vs. per-interface label spaces?
If yes, does it mean that only per-node MEPs can be encountered in the case of PWs?
 GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO, PW's Up MEP would be associated with AC and Down MEP would be associated with PW/virtual interface itself.

Dave, Italo and all,

Here are my questions:

GIM>> IMO, Up and nodal MEPs can be associated with MPLS-TP Section.

GIM>> I think that Up MEP can be instantiated with fate sharing.

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 11 Jan 2012 16:04:38 -0500

Dear Neal, et al.,
my apologies for taking discussion off-topic. I find that we're returning to question of applicability of local protection as per RFC 4090 to MPLS-TP. If I missed it being already settled and addressed, my apologies again.

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 11, 2012 8:50 AM
To: [email-masked]; David Allan I
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

regards, Neil

Dave,

What do you think?

Regards,
     Sasha

HI Sasha:

Good question!

cheers
Dave

Dave, Italo and all,

Here are my questions:

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jan 2012 08:24:11 +0200

Dear Greg,

Please see some responses inline below (orange marked [Sasha]).

Regards,
     Sasha

________________________________
From: Gregory Mirsky [[email-masked]]
Sent: Wednesday, January 11, 2012 9:57 PM
To: Alexander Vainshtein; David Allan I; [email-masked]
Cc: [email-masked]; Stewart Bryant ([email-masked])
Subject: RE: Up and Down MEPs in RFC 6371

Dear Sasha, et al.,
would offer my $.02.

 *

[[Sasha]] I tend to agree with this statement.

 *

[[Sasha]] It has been my understanding that 6371 consideres each LSP, PW or Section (in the restricted sense it uses the term) as single individual ME. Nesting of MEs is only discussed in the context of tandem connections and segments.

 *

[[Sasha]] Do you mean that all MEPs in teh given ME must belong to the same class? If so, I agree with you - in particular because I see MEPs as bi-directional (both transmiting and receiving).

 *

[[Sasha]] Well, I do not know if they are technically possible, and you doubt their practical meaning... Looks like we are converging on the same conclusion from different directions!

    Regards,
        Greg

Dave, Italo and all,
An additional question:

Is there any relationship between per-node vs. per-interface MEPs and per-platform vs. per-interface label spaces?
If yes, does it mean that only per-node MEPs can be encountered in the case of PWs?
 GIM>> I think that per-interface MEPs can be placed properly onto PW. IMO, PW's Up MEP would be associated with AC and Down MEP would be associated with PW/virtual interface itself.
[[Sasha]] What about PWs between VPLS instances? Or are those out of scope of MPLS-TP

Dave, Italo and all,

Here are my questions:

[[Sasha]] Nodal MEPs can be associated with MPLS-TP sessions in the restricted sense of 6371 (0-depth label stack), but seem to be undistinguishable from Down MEPs. But I do not understand what an Up MEP for a Section could mean - are not Sections by definition terminated on physical interfaces?

GIM>> I think that Up MEP can be instantiated with fate sharing. [[Sasha]] Well, fate-sharing within a box is always an open question...

---

From: Maarten vissers <[email-masked]>
Date: Thu, 12 Jan 2012 16:10:34 +0000

Up MEPs are used at administrative domain boundaries in the Transport Service layer (PW, service-LSP), e.g. at UNI-N and E-NNI ports.
At UNI-N ports an UP MEPs terminate a PW/service-LSP Service Provider ME and a PW/service-LSP Network Operator ME.
At ENNI ports an UP MEP terminates a PW/service-LSP Network Operator ME.

UP MEPs can also be used to test connectivity and performance of a connection through a switch fabric.

In equipment with two switch fabrics (one for transport service layer signals, second for transport path layer signals) you will have a Transport-LSP MEP which is both a Down MEP from the transport service layer switch fabric and a UP MEP from the transport path layer switch fabric. In equipment with a single switch fabric, the transport-LSP MEP is a Down MEP.

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: woensdag 11 januari 2012 20:58
To: Alexander Vainshtein; David Allan I; [email-masked]
Cc: [email-masked]; Stewart Bryant ([email-masked])
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

Dear Sasha, et al.,
would offer my $.02.

  *   in most cases, nodal MEP is identical to Down MEP
  *   ME that is terminated by Up MEPs is different from ME terminated by Down MEPs over the same LSP/PW
  *   ME can be terminated by MEP of the same class, i.e. nodal, Up or Down
  *   I don't know how practical are Up MEPs for MPLS-TP
 More notes are in-line and tagged GIM>>.

    Regards,
        Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jan 2012 18:16:38 +0200

Maarten,
Lots of thanks for an interesting input.

However, I strongly suspect that the MPLS data plane does not allow "two switching fabrics": both the server and client layer labels are looked up in the same ILM.

My reading of 3031 and even 5331 is consistent with this restriction.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten vissers
Sent: Thursday, January 12, 2012 6:11 PM
To: [email-masked]
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

Regards,
Maarten

Dear Sasha, et al.,
would offer my $.02.

    Regards,
        Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Thu, 12 Jan 2012 13:37:18 -0500

Dear Sasha,
we're converging indeed.
I've cropped thread related to ME and in-lined my notes coloring them in green:

 *

GIM>> MPLS-TP Rosetta Stone defines ME (Section 3.42) as

"... the association of two (or more) Maintenance End Points (MEPs), that should be configured and managed in order to bound the OAM responsibilities of an OAM flow [editor: definition?] across a network or sub-network, i.e. a transport path or segment, in the specific layer network that is being monitored and managed." In that context there could be Up MEP-Up MEP, MEP (nodal)-MEP (nodal), and Down MEP-Down MEP MEs if both nodal and per interface Maintanence Points (MPs) supported. Might be interesting to look whether Up-Up ME can coexist with Down-Down ME over the same MPLS-TP connection. At least from point of overlap it is plausible.

 *

GIM>> Yes, Up-Up, Nodal-Nodal, and Down-Down MEs only. Though I'm not sure that MEP can be viewed as bi-directional entity on unidirectional MPLS-TP connections, p2p and p2mp LSPs. I think it is not outside of scope of RFC 6371 but clearly outside of scope of RFC 6428.

    Regards,

        Greg

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Wednesday, January 11, 2012 10:24 PM
To: Gregory Mirsky
Cc: [email-masked]; Stewart Bryant ([email-masked]); David Allan I; [email-masked]
Subject: RE: Up and Down MEPs in RFC 6371

Dear Greg,

Regards,
     Sasha

Dear Sasha, et al.,
would offer my $.02.

 *

 *

 *

 *

    Regards,
        Greg

Dave, Italo and all,
An additional question:

Dave, Italo and all,

Here are my questions: