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

From: Eric Gray <[email-masked]>
Date: Mon, 16 Jan 2012 09:11:08 -0500

Forwarded in plain text...

________________________________

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: Thursday, January 12, 2012 1:02 AM
To: Gregory Mirsky; [email-masked]; David Allan I
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Local protection in MPLS-TP/co-ps (was RE: Up and Down MEPs in RFC 6371)

Greg, Neil, Dave and all,
A clarification: 
 
I did not mean local protection (e.g., MPLS FRR) in my original question.
Rather, I have been speaking about end-to-end linear LSP protection (e.g., as per RFC 6378).
This looks to me as MPLS-TP as it could be...
 
Regards,
     Sasha
 
________________________________

From: Gregory Mirsky [[email-masked]]
Sent: Wednesday, January 11, 2012 11:04 PM
To: [email-masked]; Alexander Vainshtein; David Allan I
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Local protection in MPLS-TP/co-ps (was RE: Up and Down MEPs in RFC 6371)

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

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,

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!

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:

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,

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. 

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: Eric Gray <[email-masked]>
Date: Mon, 16 Jan 2012 09:11:53 -0500

From: David Allan I [mailto:[email-masked]] 
Sent: Thursday, January 12, 2012 12:52 PM
To: Alexander Vainshtein; Gregory Mirsky; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Local protection in MPLS-TP/co-ps (was RE: Up and Down MEPs in RFC 6371)

Yes I got that, 
 
The example you gave was per platform labels for the client LSPs of the protected LSP. In facility protection FRR only the protection path has a server LSP....
 
cheers
Dave

Sent: Wednesday, January 11, 2012 10:02 PM

 
Regards,
     Sasha

Dear Neal, et al.,
 
    Regards,
        Greg

-        remove SA label

regards, Neil

Dave,

What do you think?

Regards,

     Sasha

HI Sasha:

Good question!

cheers

Dave

Dave, Italo and all,

An additional question:

     Sasha

Dave, Italo and all,

Here are my questions:

     Sasha