[mpls] Local protection in MPLS-TP/co-ps (was RE: Up and Down MEPs in RFC 6371)

[Gregory Mirsky <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, January 11, 2012 8:50 AM
To: [e-mail]; David Allan I
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

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: [e-mail] [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: 11 January 2012 16:38
To: David Allan I
Cc: [e-mail]; [e-mail]; Stewart Bryant ([e-mail])
Subject: Re: [mpls] Up and Down MEPs in RFC 6371

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:[e-mail]]
Sent: Wednesday, January 11, 2012 6:29 PM
To: Alexander Vainshtein; [e-mail]
Cc: [e-mail]; Stewart Bryant ([e-mail])
Subject: RE: Up and Down MEPs in RFC 6371

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:[e-mail]]
Sent: Wednesday, January 11, 2012 5:03 AM
To: David Allan I; [e-mail]
Cc: [e-mail]; Stewart Bryant ([e-mail])
Subject: RE: Up and Down MEPs in RFC 6371
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: [e-mail] [mailto:[e-mail]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, January 11, 2012 2:55 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]; Stewart Bryant ([e-mail])
Subject: [mpls] Up and Down MEPs in RFC 6371

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.

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.

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.