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

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 11 Jan 2012 12:58:53 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Alexander Vainshtein
> Sent: Wednesday, January 11, 2012 1:01 PM
> To: David Allan I
> Cc: [email-masked]; [email-masked]; Stewart Bryant
(stbryant)
> Subject: Re: [mpls] Up and Down MEPs in RFC 6371
> 
> 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.

Per-LSP label space fits perfectly with rfc5331's idea of
context-specific label space, where the context in this case is the LSP
(many implementations model a TE LSP as an interface).

eric

> 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]);
Italo.Busi@alcatel-
> lucent.com
> Subject: RE: Up and Down MEPs in RFC 6371
> 
> 
> 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]);
Italo.Busi@alcatel-
> lucent.com
> Subject: RE: 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: Alexander Vainshtein <[email-masked]>
Date: Thu, 12 Jan 2012 08:50:46 +0200

Eric,
Lots of thanks for a prompt response and an important clarification.

5331 indeed extends RFC 3031 and introduces context-specific label spaces.
However, I have been under an impression that:

1. Per-interface label space of 3031 is just a special case of the context-specific label space (with the ingress interface providing the context).
2. Additional contexts are introduced for upstream-allocated labels and not for downstream-allocated ones
3. 5331 explicitly differentiates between per-tunnel and per-interface label spaces.

This understanding is based on the text in Section 3 of 5331, e.g.:

<quote>

   When MPLS labels are upstream-assigned, the context of an MPLS label
   L is provided by the LSR that assigns the label and binds the label
   to a FEC F for a Label Switched Path (LSP) LSP1.  The LSR that
   assigns the label distributes the binding and context to an LSR Lr
   that then receives MPLS packets on LSP1 with label L.  When Lr
   receives an MPLS packet on LSP1, it MUST be able to determine the
   context of this packet.
   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.
   Another example of such a context is the neighbor from which MPLS
   packets on LSP1 may be received.  In this case, the top label of the
   MPLS packet, transmitted by the neighbor on LSP1, is looked up in a
   "Neighbor-Specific Label Space".

<end quote>

Further, RFC 5960 states that:

<quote>
   Per-platform, per-interface, or other context-specific label space
   [RFC5331] MAY be used for MPLS-TP LSPs.  Downstream [RFC3031] or
   upstream [RFC5331] label allocation schemes MAY be used for MPLS-TP
   LSPs.  The requirements of a particular LSP type may, however,
   dictate which label spaces or allocation schemes LSPs of that type
   can use.
<end quote>

To me these text suggest that:

1. P2P uni-and bi-directional LSPs in MPLS-TP use the downstream label allocation scheme and appropriate encapsulation.
2. Per-tunnel label space for this kind of tunnels is not permitted.

My reading is a bit too literal and implementations can interpret 3031 and 5331 differently.
A clarification would be very much in place IMO.

Regards,
     Sasha

________________________________________
From: Eric Osborne (eosborne) [[email-masked]]
Sent: Wednesday, January 11, 2012 8:58 PM
To: Alexander Vainshtein; David Allan I
Cc: [email-masked]; [email-masked]; Stewart Bryant (stbryant)
Subject: RE: [mpls] Up and Down MEPs in RFC 6371

Of
(stbryant)
explicitly

eric

Italo.Busi@alcatel-
multiple
path is the
assign a
per-
UP MEP
card,
Italo.Busi@alcatel-
to
in a
"last
LSP/PW to a
need for
interface of
only per-
purely an
MEPs
labels, I
different
per-
case
Of
MRPs
.
per-interface
the
the
per-node
this
'Section'
RFC 5960"
MEP for
only LERs
fate-
per-node or
miss?
LSP or
such a
in the
5960
guess
in the
case of
both
some
in (4)
inform us by
thereof.
inform us by
thereof.
inform us by
thereof.
inform us by
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.