Subject: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 11 Nov 2010 06:11:17 +0100

Dear Julien,
following your statement at today "Open discussion - MIP MEP" in the MPLS session,

I understand it if your meant that "from a deployment point of view each carrier is free to adopt the OAM capabilities that recognize are the most appropriated for its network whatever layer they are operationalized",

but I can not agree with you if you meant that "it is NOT an objective of MPLS-TP standard development to provide OAM functionalities (and generally speaking "behaviours") that are as close as possible to legacy transport network".

Best regards,
Alessandro
------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2010 05:14:54 -0000

Exactly right Alessandro.
 
We need to make a protocol mechanism that can be used to provide the function,
and that will not cause problems in nodes that do not support the function.
 
It is then an option for vendors to build their boxes, and for operators to
purchase and deploy.
 
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
D'Alessandro Alessandro Gerardo
Sent: 11 November 2010 05:11
To: [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks
 
Dear Julien,
following your statement at today “Open discussion – MIP MEP” in the MPLS
session, 
 
I understand it if your meant that “from a deployment point of view each carrier
is free to adopt the OAM capabilities that recognize are the most appropriated
for its network whatever layer they are operationalized”,
 
but I can not agree with you if you meant that “it is NOT an objective of
MPLS-TP standard development to provide OAM functionalities (and generally
speaking “behaviours”) that are as close as possible to legacy transport
network”.

Best regards,
Alessandro

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie. 
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying, printing
or use by anybody else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender by return
e-mail, Thanks. 
rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 11 Nov 2010 10:43:28 +0100

Dear Adrian,
Thank you for your response. However, it only addresses part of my comment.
What is needed is both (1) function availability AND (2) behaviors as close as possible to those of legacy transport networks (e.g. SDH).

Going back to the discussion we had during the MPLS session, that means, for example, having standards that specify a per interface MIP model that makes MPLS-TP behavior analogous to legacy transport networks in operation today.

Best regards,
Alessandro

________________________________
From: Adrian Farrel [mailto:[email-masked]]
Sent: giovedì 11 novembre 2010 6.15
To: D'Alessandro Alessandro Gerardo; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

We need to make a protocol mechanism that can be used to provide the function, and that will not cause problems in nodes that do not support the function.

It is then an option for vendors to build their boxes, and for operators to purchase and deploy.

Adrian

From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: 11 November 2010 05:11
To: [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Dear Julien,

Best regards,
Alessandro

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
Rispetta l'ambiente. Non stampare questa mail se non è necessario.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2010 09:58:25 -0000

Resend with trimmed text.

Hi,

I think the difference in the way we are presenting this lies in me saying that
we have to have a model and tools that allow vendors to build equipment that
allows operators to deploy MPLS-TP networks that follow the "legacy transport
network" mode of operation.

It seems to me that you are saying that the architecture must prohibit people
from building and deploying in other modes, and I can't see the value of that
prohibition.

Adrian

From: D'Alessandro Alessandro Gerardo
[mailto:[email-masked]] 
Sent: 11 November 2010 09:43
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Dear Adrian,
Thank you for your response. However, it only addresses part of my comment. 
What is needed is both (1) function availability AND (2) behaviors as close as
possible to those of legacy transport networks (e.g. SDH).

Going back to the discussion we had during the MPLS session, that means, for
example, having standards that specify a per interface MIP model that makes
MPLS-TP behavior analogous to legacy transport networks in operation today.

Best regards,
Alessandro
________

Adrian

Dear Julien,

Best regards,
Alessandro

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 11 Nov 2010 13:30:58 +0200

Alessandro, and all,
IMHO "As close as possible" is a vague definition at best. Let's keep in mind that one "hard" restriction on MPLS-TP is that its data plane is the same as that of IP/MPLS.  E.g., "hard" hierarchy of SDH layers cannot be reproduced by the LSP hierarchy  because interpretation of a received label by an LSR does not depend on the level at which this label has been found in the label stack. (This is just an example that is not necessarily related to the problem you are raising).

When it comes to the specific problem you raise, the MPLS-TP OAM Requirements<http://datatracker.ietf.org/doc/rfc5860/?include_text=1> document explicitly defines that MIPs refer to nodes, as can be seen from the following text from Section 1.2 :
In this document, we:
...
   o  refer to a Label Edge Router (LER), for a given LSP or Section,
      and to a PW Terminating Provider Edge (T-PE), for a given PW, as
      an End Point.  Further, we refer to a Label Switching Router
      (LSR), for a given LSP, and to a PW Switching Provider Edge
      (S-PE), for a given PW, as an Intermediate Point.  This document
      does not make a distinction between End Points (e.g., source and
      destination) as it can be inferred from the context of the
      sentences.

   o  use the term "node" as a general reference to End Points and
      Intermediate Points.
I.e., the requirement you now state seems to be beyond what has been agreed upon in the IETF with regard to MPLS-TP OAM.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of D'Alessandro Alessandro Gerardo
Sent: Thursday, November 11, 2010 11:43 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Dear Adrian,

Best regards,
Alessandro

Adrian

Dear Julien,

Best regards,
Alessandro

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 11:40:31 +0000

Sasha,

One can retain sublayering in MPLS-TP like MPLS if one wants.  In this case it is not a transprent transport network....retaining PWs is nd an even more clear indication of failing as a transprenet transport network.   I've explained why this is lots of times before on the mail list.  So if we do this (and we have) then all we need to say is that MPLS-TP is just another spin of MPLS with the major merging problem removed and some attempt at an OOB CP...it is however, *not* a transparent transport network...just a technical fact.

regards, Neil

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: 11 November 2010 11:31
To: D'Alessandro Alessandro Gerardo
Cc: [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Alessandro, and all,

Regards,
     Sasha

Dear Adrian,

Best regards,
Alessandro

Adrian

Dear Julien,

Best regards,
Alessandro

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 11 Nov 2010 15:20:23 +0200

Neil,
Lots of thanks for a prompt response.
I think that there we deal here with two separate issues:

1.       What is within the scope of the MPLS-TP toolset as developed by the IETF, and what is out of this scope? One possible answer to that question, in accordance with the IETF tradition, is "whatever has gained rough IETF consensus and has been implemented by running code". Please note that this answer does not per se imply that all the in-scope tools are useful for any meaningful purpose:)

2.       Is MPLS-TP, as developed by the IETF, a suitable technology for building packet transport networks. Your answer seems to be quite unequivocal. IMHO, the ultimate answer to this question will be only obtained in future.

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 11, 2010 1:41 PM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

regards, Neil

Regards,
     Sasha

Dear Adrian,

Best regards,
Alessandro

Adrian

Dear Julien,

Best regards,
Alessandro

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 11 Nov 2010 15:41:22 +0100

Hi Andrian,
please see my comments in line...

best regards,
Alessandro
Sent: giovedì 11 novembre 2010 10.55

Hi,

I think the difference in the way we are presenting this lies in me saying that we have to have a model and tools that allow vendors to build equipment that allows operators to deploy MPLS-TP networks that follow the "legacy transport network" mode of operation.
[Alessandro] It seems to me we are claiming the same thing

It seems to me that you are saying that the architecture must prohibit people from building and deploying in other modes, and I can't see the value of that prohibition.
[Alessandro] No, I haven't said that. I said the architecture must include all the constructs that are required to get the above mentioned goal (e.g. a per interface MIP).

Adrian

From: D'Alessandro Alessandro Gerardo [mailto:[email-masked]]
Sent: 11 November 2010 09:43
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Dear Adrian,

Best regards,
Alessandro

Adrian

Dear Julien,

Best regards,
Alessandro

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 11 Nov 2010 16:20:54 +0000

Sasha,

You raise a point that makes me think that I am possibly approaching MPLS-TP OAM with a different perspective to some others on this (and the ITU) list...

On 11 Nov 2010, at 11:30, Alexander Vainshtein wrote:
> Alessandro, and all,
> IMHO “As close as possible” is a vague definition at best.

In my mind what it means is that a member of the operations team can perform their job with the minimum amount of changes to their standard operating procedures, in other words the steps they take, the results they are presented (e.g. alarms, output of diagnostic tools) etc are as similar to what they are familiar with as possible.

The analogy I could draw (which may not work completely) would be the development of bicycle technology.

In approximately 1870 the penny farthing was invented, while they had their disadvantages they had advantages over the velocipedes of the time and so became popular. Over the next 15 or so years technology developed and penny-farthings became less popular and the safety bicycle took over in popularity and still remain popular through to the present day.

There were very few similarities between the penny-farthing & the safety bicycle in terms of the mechanics of how they worked and the technology they used, e.g.:
- The penny farthing had wheels of different sizes, solid tyres & the pedals directly drove the front wheel
- The safety bicycle had wheels of the same size, pneumatic tyres and used a chain drive between the pedals & the rear wheel.

However, because both used handle bars to steer and were driven by the rider pushing pedals with their feet (i.e. their standard operating procedures were the same), a rider familiar with using a penny farthing could easily pick up & use a safety bicycle without requiring additional training.

In other words, the internal technology is far less relevant than the external interface to the user. I see PTN OAM technology in a similar vein - the internal OAM protocols & PDUs etc are far less relevant than the way those protocols & PDUs are used to expose an interface (e.g. alarms, diagnostic tools, etc.) to operations personnel.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Nov 2010 16:28:56 -0000

Hi,

>> I think the difference in the way we are presenting this lies in me saying
>> that we have to have a model and tools that allow vendors to build
>> equipment that allows operators to deploy MPLS-TP networks that
>> follow the "legacy transport network" mode of operation.
>
>> It seems to me that you are saying that the architecture must prohibit 
>> people from building and deploying in other modes, and I can't see
>> the value of that prohibition.
>
> [Alessandro] No, I haven't said that. I said the architecture must include
> all the constructs that are required to get the above mentioned goal
> (e.g. a per interface MIP). 

My apologies. It looks like we are perfectly aligned.
In addition, I believe that the OAM Framework (section 3.4 already includes the
function). So I think we are done.

Adrian

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 12 Nov 2010 12:36:42 +0200

Adrian,
I've looked up the MPLS-TP OAM framework draft and it indeed discusses per-interface MIPs that have not been considered (according to my reading)  in RFC 5654.

I think that, at the very least, the notion of a per-interface MIP requires additional clarification. E.g., can you introduce a per-interface MIP in an LSP that uses labels from the per-platform space?
On a more generic level, taking into account that the only way to reach a MIP in an LSP is to send a packet that would experience TTL expiration in the node of interest, what is the difference in behavior of LSPs with configured MIPs and LSPs without them? 

I also note that the framework draft still promotes hierarchy of labels for SPMEs and/or TCM.
I believe that I've commented on this concept earlier, and in any case I plan to send an IESG LC comment on this point: IMO my previous comments in this regard have not been resolved.

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adrian Farrel [[email-masked]]
Sent: Thursday, November 11, 2010 6:28 PM
To: 'D'Alessandro Alessandro Gerardo'
Cc: [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP   networks

Hi,

Adrian

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 12 Nov 2010 13:15:43 +0200

Ben,
Lots of thanks for an excellent analogy. It shows quite nicely the extent to which "as close as possible" approach can work.

My personal preference is a comparison between two transport technologies: railways vs. lorries.

Both are used to deliver people and goods across land; and both use wheels as a critical element.

However, I would not expect an experienced steam engine driver being allowed to drive a heavy truck without taking appropriate courses, passing the test and obtaining a license (and vice versa).

I'd also say that the idea of bypassing another train in the middle of the road as part of normal operation would sound a  bit strange to the steam engine driver, while the lorry drivers would not probably be happy if they were told never to bypass other cars on the road.

And while the wheels need maintenance in both cases, the techniques used for detecting a faulty wheel are different: striking a pneumatic tire with a small hammer would not produce the expected "clang" regardless of the state of the tire (and, by implication, hearing disabilities would not disqualify a person from checking tires) while kicking a wheel of a railway car (a popular if not quite standardized method of checking air pressure in many places) could easily end with a broken toe.

My 2c,
     Sasha

________________________________________
From: Ben Niven-Jenkins [[email-masked]]
Sent: Thursday, November 11, 2010 6:20 PM
To: Alexander Vainshtein
Cc: D'Alessandro Alessandro Gerardo; [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

Ben

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Sun, 14 Nov 2010 23:54:38 +0100

Sasha,

See in line marked with [ib]

Thanks in advance

Italo

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto
> di Alexander Vainshtein
> Inviato: venerdì 12 novembre 2010 11.37
> A: [email-masked]
> Cc: [email-masked]
> Oggetto: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> Adrian,
> I've looked up the MPLS-TP OAM framework draft and it indeed discusses
> per-interface MIPs that have not been considered (according to my reading)
> in RFC 5654.
> 
> I think that, at the very least, the notion of a per-interface MIP
> requires additional clarification. E.g., can you introduce a per-interface
> MIP in an LSP that uses labels from the per-platform space?

[ib] Could you be more specific about how the label space impacts the support of per-interface vs per-node MIP?

> On a more generic level, taking into account that the only way to reach a
> MIP in an LSP is to send a packet that would experience TTL expiration in
> the node of interest, what is the difference in behavior of LSPs with
> configured MIPs and LSPs without them?
> 

[ib] We discussed this point during the development of the OAM framework and we have agreed that every node has MIP(s) and that the operator can disable them. See the following text extracts from section 3.4:

   An intermediate node within a MEG can either:

   o Support per-node MIP (i.e. a single MIP per node in an
      unspecified location within the node);

   o Support per-interface MIP (i.e. two or more MIPs per node on
      both sides of the forwarding engine).

And

   Once a MEG is configured, the operator can enable/disable the
   MIPs on the nodes within the MEG. All the intermediate nodes and
   possibly the end nodes host MIP(s). Local policy allows them to
   be enabled per function and per MEG. The local policy is
   controlled by the management system, which may delegate it to
   the control plane.

I hope this would help.

> I believe that I've commented on this concept earlier, and in any case I
> plan to send an IESG LC comment on this point: IMO my previous comments in
> this regard have not been resolved.
> 

[ib] Could you please re-send your comment? This would help expediting its resolution as I fear we have missed it. I apologize for that.

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Nov 2010 09:03:17 +0200

Italo,

I will look up my archives and resend the specific comment regarding SPME. 
But the gist of this comment has been, that SPME is a new LSP, so that monitoring it does not necessarily say anything about the original LSP passing thru the segment in question. The simplest use case demonstrating the difference is a case of incomplete configuration, when the original LSP has not been configured in one of the internal nodes of the segment, but SPME was (and vice versa).

Regarding MIPs, I'd like to explain my doubts.

1. We all agree (or so it seems) that intermediate points of LSPs and PWs can only be reached due to TTL expiration. 
2. By default TTL expiration extracts a packet from the data plane and sends it to the control plane instead.
    As per RFC 4379, this process includes preservation of the original received label stack 
    and noting the actual ingress interface so that they are available for the CP processing.
3. Taking (1) and (2) above as given, could you please clarify, what exactly does it mean if:
    (a) A per-node MIP is disabled? 
    (b) A per-interface MIP is disabled?
4. Are MIPs bound to specific Managed Entities (LSPs)? If they are, what should happen if:
    a) An LSP uses labels from the per-platform label stace, and hence packets associated with this LSP can
        be received from any interface?
    b) A per-interface MIP is enabled for this LSP on one interface and disabled on another one?

Regards,
     Sasha

________________________________________
From: BUSI, ITALO (ITALO) [[email-masked]]
Sent: Monday, November 15, 2010 12:54 AM
To: Alexander Vainshtein; [email-masked]
Cc: [email-masked]
Subject: R: [mpls-tp] about open discussion about MIP MEP in    MPLS-TP networks

Sasha,

Thanks in advance

Italo

And

I hope this would help.

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Nov 2010 03:34:35 -0800

Dear Sasha,
this topic is of interest for me too and I'm trying to find answers on
questions you've raised. Please find my comments inline tagged with GIM>>

Regards,
Greg

On Sun, Nov 14, 2010 at 11:03 PM, Alexander Vainshtein <
[email-masked]> wrote:

> But the gist of this comment has been, that SPME is a new LSP, so that
> monitoring it does not necessarily say anything about the original LSP
> passing thru the segment in question. The simplest use case demonstrating
> the difference is a case of incomplete configuration, when the original LSP
> has not been configured in one of the internal nodes of the segment, but
> SPME was (and vice versa).
>
GIM>> In some aspect I consider SPME OAM to Segment OAM in the same way as
LSP OAM to PW OAM.

> 1. We all agree (or so it seems) that intermediate points of LSPs and PWs
> can only be reached due to TTL expiration.
GIM>> Some nodes would support nodal MIP or per interface MIP only. Would
there be NEs that support both or support of per interface MIP implies
support of nodal MIP? Assuming that per-node MIP supported by NE for given
ME and is disabled, directed to this MIP OAM packet will be dropped.

>    (b) A per-interface MIP is disabled?
GIM>> I believe that OAM packet will be dropped.

> 4. Are MIPs bound to specific Managed Entities (LSPs)?

GIM>> My understanding is that MIP exists in the context of specific ME.

> If they are, what should happen if:
GIM>> E.g. bypass tunnel.

>    b) A per-interface MIP is enabled for this LSP on one interface and
GIM>> I think that your example underscores terminology issue. Perhaps
"per-interface MIP" is not the best term. It could be that "in-MIP" and
"out-MIP" are mode suitable to differentiate from nodal MIP.

> [ib] Could you be more specific about how the label space impacts the
> support of per-interface vs per-node MIP?
>
> [ib] We discussed this point during the development of the OAM framework
> and we have agreed that every node has MIP(s) and that the operator can
> disable them. See the following text extracts from section 3.4:
>
> [ib] Could you please re-send your comment? This would help expediting its
> resolution as I fear we have missed it. I apologize for that.
>
> > Regards,
> >      Sasha
> >

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Nov 2010 13:57:49 +0200

Dear Greg,
Lots of thanks for a prompt and detailed response.

I agree with you that we have some terminological issues here. But I am trying to deal with the text "as is", and this text in currently in the IESG LC.
If terminology is ambiguous, it should be revised before approval, not after.
I also  think that that there are some technical issues that have to be resolved that go beyond pure terminology.
Please see more comments inline below (green italics).

Regards,
     Sasha

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, November 15, 2010 1:35 PM
To: Alexander Vainshtein
Cc: BUSI, ITALO (ITALO); [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Dear Sasha,
this topic is of interest for me too and I'm trying to find answers on questions you've raised. Please find my comments inline tagged with GIM>>

Regards,
Greg
On Sun, Nov 14, 2010 at 11:03 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Italo,
Lots of thanks for a prompt response.
I will look up my archives and resend the specific comment regarding SPME.
But the gist of this comment has been, that SPME is a new LSP, so that monitoring it does not necessarily say anything about the original LSP passing thru the segment in question. The simplest use case demonstrating the difference is a case of incomplete configuration, when the original LSP has not been configured in one of the internal nodes of the segment, but SPME was (and vice versa).
GIM>> In some aspect I consider SPME OAM to Segment OAM in the same way as LSP OAM to PW OAM.
[[[Sasha]]]  I do not think this is a valid comparison. A PW always runs within some tunnel, but SPME is (potentially)  set up on demand and dissolved once there is no need in it. Hence failures detected by the tunnel OAM are meaningful for the observed behavior of PWs using this tunnel; but failures (or lack thereof) in SPME are not necessarily meaningful for the behavior of the original LSP in the absence of SPME.

1. We all agree (or so it seems) that intermediate points of LSPs and PWs can only be reached due to TTL expiration.
2. By default TTL expiration extracts a packet from the data plane and sends it to the control plane instead.
   As per RFC 4379, this process includes preservation of the original received label stack
   and noting the actual ingress interface so that they are available for the CP processing.
3. Taking (1) and (2) above as given, could you please clarify, what exactly does it mean if:
   (a) A per-node MIP is disabled?
GIM>> Some nodes would support nodal MIP or per interface MIP only. Would there be NEs that support both or support of per interface MIP implies support of nodal MIP?
[[[Sasha]]] Please note that MIPs are enabled by default (i.e., packets with expired TTL go o the CP). Hence an interesting question: which MIP - a nodal one or a per-interface one - is enabled by default?
 Assuming that per-node MIP supported by NE for given ME and is disabled, directed to this MIP OAM packet will be dropped.
[[[Sasha]]] This is a reasonable approach, but it is not mentioned in the draft.
   (b) A per-interface MIP is disabled?
GIM>> I believe that OAM packet will be dropped.
[[[Sasha]]] Does this mean that an OAM packet received from an interface on which MIP is enabled would be dropped but it would be handled if it is received from another interface (Assume that the label which represents the ME is from the per-platform space)?
4. Are MIPs bound to specific Managed Entities (LSPs)?
GIM>> My understanding is that MIP exists in the context of specific ME. [[[Sasha]]]  So is mine. But I do not think that the draft really goes into it.
If they are, what should happen if:
   a) An LSP uses labels from the per-platform label stace, and hence packets associated with this LSP can
       be received from any interface?
GIM>> E.g. bypass tunnel. [[[Sasha]]]  Yes
   b) A per-interface MIP is enabled for this LSP on one interface and disabled on another one?
GIM>> I think that your example underscores terminology issue. Perhaps "per-interface MIP" is not the best term. It could be that "in-MIP" and "out-MIP" are mode suitable to differentiate from nodal MIP. [[[Sasha]]]  Such a change would be probably useful. Especially because per-interface has a very specific connotation.

Regards,
    Sasha

________________________________________
From: BUSI, ITALO (ITALO) [[email-masked]<mailto:[email-masked]>]
Sent: Monday, November 15, 2010 12:54 AM
To: Alexander Vainshtein; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: R: [mpls-tp] about open discussion about MIP MEP in    MPLS-TP networks

Sasha,

Thanks in advance

Italo

> Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Per conto
> di Alexander Vainshtein
> A: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>

And

I hope this would help.

> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of
> Adrian Farrel [[email-masked]<mailto:[email-masked]>]
> Cc: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Nov 2010 14:29:10 +0200

Italo,
My original comment on SPME has been sent to the list on 07-Jul-10.
You can see it at http://www.ietf.org/mail-archive/web/mpls-tp/current/msg04369.html .
It has not been posted as an LC comment, presumably because the draft has not been in any kind of LC at that moment.

Adrian, 
Please consider this comment as an IESG LC comment.

Regards,
     Sasha

-----Original Message-----
From: Alexander Vainshtein 
Sent: Monday, November 15, 2010 9:03 AM
To: BUSI, ITALO (ITALO)
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Italo,

Regards,
     Sasha

Sasha,

Thanks in advance

Italo

And

I hope this would help.

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Nov 2010 11:10:51 +0100

Sasha,

> sends it to the control plane instead.

Do you refer to 'control plane' as e.g. a LDP or GMPLS control plane?
If so, then in packet transport network applications without such control
plane the MIP feature would not be available at all.

Regards,
Maarten

> Sent: 15 November 2010 08:03
> To: BUSI, ITALO (ITALO)
> Cc: [email-masked]
> passing thru the segment in question. The simplest use case
> demonstrating the difference is a case of incomplete configuration,
> when the original LSP has not been configured in one of the internal
> nodes of the segment, but SPME was (and vice versa).
> 
> 1. We all agree (or so it seems) that intermediate points of LSPs and
> PWs can only be reached due to TTL expiration.
> [ib] We discussed this point during the development of the OAM
> framework and we have agreed that every node has MIP(s) and that the
> operator can disable them. See the following text extracts from section
> 3.4:
> 
> > I also note that the framework draft still promotes hierarchy of
> labels
> > for SPMEs and/or TCM.
> [ib] Could you please re-send your comment? This would help expediting
> its resolution as I fear we have missed it. I apologize for that.
> 
> > Regards,
> >      Sasha
> >
> > From: [email-masked] [[email-masked]] On Behalf
> Of
> > Adrian Farrel [[email-masked]]
> > >> I think the difference in the way we are presenting this lies in
> me
> > saying

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 22 Nov 2010 11:50:07 +0100

Sasha,

See inline...

> PWs can only be reached due to TTL expiration.

[maarten] That is what MPLS experts tell me; so this is the assumption for
MPLS-TP.

> sends it to the control plane instead.

[maarten] see my previous email. Packet transport network equipment without
control plane are required to support MIP functions as well.

>     and noting the actual ingress interface so that they are available

[maarten] in nodes with and without control plane these OAM packets have to
be processed as if the MIP is functionally located on the ingress port.
Per-node and per-interface are two **implementation alternatives** within
equipment. The ITU-T functional models provide an unambiguous requirement of
the functional location of a half-MIP or MIP function in each interface
port. Both implementation alternatives must comply with the behaviour
specified by the functional model.

>     (a) A per-node MIP is disabled?

[maarten] A per-node MIP is an implementation of two Down half-MIP
functions, one located at NNI port A and the other located at NNI port B.
The PW/LSP is set up over ports A and B. Those Down half-MIP functions are
able to accept e.g. loopback requests that arrive via the physical port, and
are unable to accept such requests that arrive via the fabric.

[maarten] the 'Down half-MIP function' on a NNI port is disabled, and OAM
packets destined for this function will not be processed.

>     (b) A per-interface MIP is disabled?

[maarten] A per-interface MIP is an implementation of a MIP function (i.e.
two back-to-back half-MIP functions) on each NNI port. Those MIP functions
are able to accept e.g. loopback requests that arrive via the physical port,
and such requests that arrive via the fabric.

[maarten] the 'MIP function' on a NNI port is disabled, and OAM packets
destined for this function will not be processed.

> 4. Are MIPs bound to specific Managed Entities (LSPs)? 

[maarten] MIPs and half-MIPs are bound to Managed Entities (PWs, LSPs,
Sections).

>     a) An LSP uses labels from the per-platform label stace, and hence
> packets associated with this LSP can be received from any interface?

[maarten] In MPLS-TP merging is not supported. As such per-platform labels
are 1-to-1 associated with a single NNI port. E.g. if Label 500 is
associated with a PW or LSP on NNI port X, then reception of a packet with
label 500 on NNI port Y (X<>Y) must be discarded.

>     b) A per-interface MIP is enabled for this LSP on one interface and

[maarten] Assume that LSP X with endpoint a (EPa) and z (EPz) is transported
via NNI ports P and Q in a node. Assume that the per-interface MIP on port P
is enabled and on port Q is disabled. This implies that e.g. a LSP loopback
OAM packet from EPa or EPz can be looped on NNI port P and can not be looped
on NNI port Q.

Regards,
Maarten

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 22 Nov 2010 13:59:56 +0200

Maarten,
Lots of thanks for an important question.

TTL expiration results in taking the packet out of the normal data path forwarding and passing it to a dedicated handler (e.g., CPU). This is not related to LDP or GMPLS. 
In fact, in IP/MPLS this handler typically supports LSP-Ping in trace mode (see RFC 4379 for details), which is neither LDP nor RSVP-TE.

I admit that I've used the term "control plane" in a way that could be misinterpreted. Hopefully this note resolves your concerns.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, November 22, 2010 12:11 PM
To: Alexander Vainshtein; 'BUSI, ITALO (ITALO)'
Cc: [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

Regards,
Maarten

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 22 Nov 2010 15:40:43 +0200

Maarten,

Please see some answers inline below. 
I will snip the fragments where we seem to be in agreement in hope that this will improve readability.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Monday, November 22, 2010 12:50 PM
To: Alexander Vainshtein; 'BUSI, ITALO (ITALO)'
Cc: [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

See inline...

> nodes of the segment, but SPME was (and vice versa).
[[[Sasha]]] Looks like you've decided not to comment on this point. 
Does it mean that you agree with me that there is an issue with SPME?

[maarten] That is what MPLS experts tell me; so this is the assumption for
MPLS-TP.
[[[Sasha]]] Great! So at least here we are on the same page.

[maarten] see my previous email. Packet transport network equipment without
control plane are required to support MIP functions as well.
[[[Sasha]]] I've already explained that in a separate email.

[maarten] in nodes with and without control plane these OAM packets have to
be processed as if the MIP is functionally located on the ingress port.
[[[Sasha]]] Please note that this is basic MPLS data plane functionality that does not depend on configuration of MIPs. Or, if you prefer it in a different way, a per-node MIP is by default enabled in any MPLS node.

[maarten] Per-node and per-interface are two **implementation alternatives** within
equipment. The ITU-T functional models provide an unambiguous requirement of
the functional location of a half-MIP or MIP function in each interface
port. Both implementation alternatives must comply with the behaviour
specified by the functional model.
[[[Sasha]]] Do ITU-T functional models match ITU-T-standardized SDH equipment in this regard?
If yes, could you please explain how a MIP half-function on an egress SDH port is mapped to the ITU-T model of SDH?
This explanation would be most helpful.

[maarten] A per-node MIP is an implementation of two Down half-MIP
functions, one located at NNI port A and the other located at NNI port B.
[[[Sasha]]] I disagree. A per-node MIP is not, IMHO, related to any specific port.
If the model does not support this kind of MIP, the problem is with the model IMO.

[maarten] The PW/LSP is set up over ports A and B. Those Down half-MIP functions are
able to accept e.g. loopback requests that arrive via the physical port, and
are unable to accept such requests that arrive via the fabric.
[[[Sasha]]] Is the Fabric a mandatory element in the ITU-T functional model? 
What is going to happen to Fabric-less implementations?

[maarten] In MPLS-TP merging is not supported. As such per-platform labels
are 1-to-1 associated with a single NNI port. E.g. if Label 500 is
associated with a PW or LSP on NNI port X, then reception of a packet with
label 500 on NNI port Y (X<>Y) must be discarded.
[[[Sasha]]] To the best of my understanding this is not how the labels from the per-platform label space are treated in IP/MPLS. And RFC 5960 which lists all specific deviations from the IP/MPLS data plane that MPLS-TP introduces, does not list any such as well.
What's more, PW labels MUST be allocated from the per-platform label space (as per RFC 4447) and, AFAIK, are accepted on all MPLS-enabled physical ports in most (if not all)implementations. And RFC 5690 explicitly states that it does not specify any deviations for the PW data plane for MPLS-TP.

Regards,
Maarten

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Mon, 22 Nov 2010 19:05:59 +0100

Sasha,

See my comments in line marked with [ib]

Thanks, Italo

> Da: Alexander Vainshtein [mailto:[email-masked]]
> Inviato: lunedì 22 novembre 2010 14.41
> A: Maarten Vissers
> Cc: [email-masked]; BUSI, ITALO (ITALO)
> Oggetto: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
>
> Maarten,
>

[ib] I think there is not disagreement here: see section 3.8 of the OAM Framework well as draft-koike-mpls-tp-temporal-hitless-psm and draft-zhang-mpls-tp-path-segment-monitoring.

> [[[Sasha]]] Great! So at least here we are on the same page.

[ib] I think this is described in section 3.4 of the OAM Framework:

   When sending an OAM packet to a MIP, the source MEP should set
   the TTL field to indicate the number of hops necessary to reach
   the node where the MIP resides.

   The source MEP should also include Target MIP information in the
   OAM packets sent to a MIP to allow proper identification of the
   MIP within the node. The MEG the OAM packet is associated with
   is inferred from the MPLS label.

[ib] I am less familiar with the MIP/MEP Map draft but when I read it I understood it to be aligned with the OAM Framework.

> [[[Sasha]]] Please note that this is basic MPLS data plane functionality
> that does not depend on configuration of MIPs. Or, if you prefer it in a
> different way, a per-node MIP is by default enabled in any MPLS node.
>

[ib] I think that neither the OAM Framework nor the MIP/MEP Map precludes the implementation of per-node MIPs. However, they allow also the implementation of per-interface MIPs.

> If yes, could you please explain how a MIP half-function on an egress SDH
> port is mapped to the ITU-T model of SDH?

[ib] According to section 3.4 of the OAM Framework, a per-node MIP is located in an unspecified location within the node. What Maarten describes is the way we can model such a MIP using the ITU-T functional components.
In any case, the conclusion is the same: when a per-node MIP is disabled, all OAM packets addressed to it are discarded.

> destined for this function will not be processed.

[ib] Correct: when a per-node MIP is disabled, all OAM packets addressed to it are discarded.

> [[[Sasha]]] To the best of my understanding this is not how the labels
> from the per-platform label space are treated in IP/MPLS. And RFC 5960
> which lists all specific deviations from the IP/MPLS data plane that MPLS-
> TP introduces, does not list any such as well.
> What's more, PW labels MUST be allocated from the per-platform label space
> (as per RFC 4447) and, AFAIK, are accepted on all MPLS-enabled physical
> ports in most (if not all)implementations. And RFC 5690 explicitly states
> that it does not specify any deviations for the PW data plane for MPLS-TP.
>

[ib] Please refer to Errata 2534. However, this is a MAY, so the problem you raise can happen (I guess you are considering the case the OAM packet is addressed to the per-interface MIP at the ingress side because the one at the egress side can still be addressed).
In such a case, the per-interface MIP on the ingress side does not receive the OAM packet and does not reply. The OAM packet is received by the per-interface MIP on the egress side that drops it because it is not addressed to it.

> OAM packet from EPa or EPz can be looped on NNI port P and can not be

[ib] In a nutshell, the disabled per-interface MIP is dropping all the oAM packets addressed to itself (and not replying to them)

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Mon, 22 Nov 2010 19:23:55 +0100

Sasha, Greg,

see further considerations in line marked with [ib]

Text removed to fit mailing list constraints is replaced by <...>

Thanks, Italo

________________________________
Da: Alexander Vainshtein [mailto:[email-masked]]
Inviato: lunedì 15 novembre 2010 12.58
A: Greg Mirsky
Cc: BUSI, ITALO (ITALO); [email-masked]
Oggetto: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Dear Greg,
<...>

Regards,
     Sasha

Dear Sasha,

Regards,
Greg
<...>
[ib] Implementation decision

 Assuming that per-node MIP supported by NE for given ME and is disabled, directed to this MIP OAM packet will be dropped.
[[[Sasha]]] This is a reasonable approach, but it is not mentioned in the draft.
[ib] Which draft? Do we need to specify all these details in the OAM Framework?

   (b) A per-interface MIP is disabled?
GIM>> I believe that OAM packet will be dropped.
[[[Sasha]]] Does this mean that an OAM packet received from an interface on which MIP is enabled would be dropped but it would be handled if it is received from another interface (Assume that the label which represents the ME is from the per-platform space)?
4. Are MIPs bound to specific Managed Entities (LSPs)?
GIM>> My understanding is that MIP exists in the context of specific ME. [[[Sasha]]]  So is mine. But I do not think that the draft really goes into it.
[ib] Section 3.4 of the OAM Framework says:
A MEG Intermediate Point (MIP) is a function located at a point
between the MEPs of a MEG for a PW, LSP or SPME.

[ib] This is different than receiving a packet from an "unexpected" interface. A bypass tunnel is an expected interface that will be used in case of a recovery condition. In this case, another per-interface MIP is located on this interface and that MIP will become reachable only under recovery conditions: recovery actions are basically changing the route of an LSP.

   b) A per-interface MIP is enabled for this LSP on one interface and disabled on another one?
GIM>> I think that your example underscores terminology issue. Perhaps "per-interface MIP" is not the best term. It could be that "in-MIP" and "out-MIP" are mode suitable to differentiate from nodal MIP. [[[Sasha]]]  Such a change would be probably useful. Especially because per-interface has a very specific connotation.
[ib] I think that "in-MIP" and "out-MIP" terminology is also confusing. With co-routed bidirectional LSPs, the in-MIP in one direction coincides with the out-MIP in the reverse direction.
I think that the source of the confusion is the association of the term "interface" with a physical rather than logical entity. I discussed a similar issues in the context of the Identifiers draft and the following clarification text was added as a result of that discussion: "An interface is the Access Point (AP) to a server layer MPLS-TP section or MPLS-TP tunnel."
I think this text is not 100% accurate, so I would propose to add the following definition of Interface to the OAM Framework draft:

An interface is the Access Point (AP) to a server (sub-)layer e.g., MPLS-TP section or MPLS-TP tunnel.

Would this change resolve the issue?

<...>

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Mon, 22 Nov 2010 19:26:05 +0100

Sasha,

I think that a comment similar to yours have been raised during WG LC and resolved by adding section 3.8

Please let us know if there are any specific issues with section 3.8 you wish to be addressed as part of the IETF LC.

Thanks, Italo

> Inviato: lunedì 15 novembre 2010 13.29
> A: BUSI, ITALO (ITALO)
> Cc: [email-masked]; [email-masked]; [email-masked]
> It has not been posted as an LC comment, presumably because the draft has
> not been in any kind of LC at that moment.
> 
> Adrian,
> the difference is a case of incomplete configuration, when the original
> LSP has not been configured in one of the internal nodes of the segment,
> but SPME was (and vice versa).
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 23 Nov 2010 16:01:09 +0200

Italo,
In this response I  will only refer to your proposal to modify the definition of an interface:
An interface is the Access Point (AP) to a server (sub-)layer e.g., MPLS-TP section or MPLS-TP tunnel
I would strongly object to such a modification, because the notion of an interface is widely used in MPLS and commonly associated with a physical link (or a group of such links as in the case of bundled links).

E.g., when RFC 3031 discusses per-platform and  per-interface label spaces, it, IMHO, explicitly implies that an LSP cannot be treated as an interface for the purpose of specifying per-interface label spaces. This follows from the requirement that received labels are processed regardless of their position in the label stack. RFC 5031 actually enforces this interpretation as well when it defines "per upstream peer" label spaces and defines methods for their specification (again, this is done in such a way as to preclude an LSP being treated as an interface).

Regards,
     Sasha

From: BUSI, ITALO (ITALO) [mailto:[email-masked]]
Sent: Monday, November 22, 2010 8:24 PM
To: Alexander Vainshtein; Greg Mirsky
Cc: [email-masked]
Subject: R: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha, Greg,

Thanks, Italo

Dear Greg,
<...>

Regards,
     Sasha

Dear Sasha,

Regards,
Greg

<...>

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 23 Nov 2010 15:12:41 +0100

Sasha,

The last item you commented on below (per platform label space) constitutes
a security risk...

See inline for this and other comment...

> Does it mean that you agree with me that there is an issue with SPME?

[Maarten] SPME should have been an encoding method of a Maintenance Entity
Group level within a connection. Unfortunately it is an insufficient
encoding method, which does not comply with the full behaviour associated
with such MEG level. I.e. it does not maintain the original connection.
Correct encoding methods are the use of a MEG level field within the OAM
packets, or use of a label stack entry header with a reserved label value
immediately below the 'label stack entry header with the connection
identifying label' (refer to my proposals for a "label_12" some time ago).
The requirements are well known for many years, but it was decided to ignore
this requirement in MPLS-TP; I have the impression that it was more
important to not extend the MPLS hardware, than to comply with this
requirement. I consider this approach a well known characteristic of MPLS-TP
development. 

[Maarten] Ethernet VLAN OAM doesn't have this problem, and therefore the RMP
and MP2MP VLANs (HVPLS instances) comply with the required MEG level
behaviour. As the MEF Ethernet E-NNI applies to both the RMP/MP2MP and
P2P/P2MP connections, many operators seem to operate an Ethernet VLAN layer
above the MPLS-TP transport technology. If so, the UNI-to-UNI layer is an
Ethernet VLAN (ETH) layer and the actual 'transport service' layer OAM is
the Ethernet VLAN OAM. PW OAM in this case would just be a SPME type of OAM
for those VLAN connections. 

[Maarten] It is possible to deploy VLANs/HVPLS instances also for the P2P
E-line and TDM services in a MPLS-TP network, and activate/deactivate
Ethernet VLAN MEG level OAM. PWs would only be SS-PWs without monitoring and
thus without PW related SPMEs.

> [[[Sasha]]] Great! So at least here we are on the same page.

[Maarten] My personal believe is that this method is a poor man's method,
only present in MPLS-TP. Other technologies have much better methods. But as
a better method would imply an extension of today's MPLS hardware, such
method is not acceptable by the controlling powers in MPLS. Our industry
simply has to live with such poor man's solution.

> 
> > 2. By default TTL expiration extracts a packet from the data plane
> and
> > sends it to the control plane instead.
> 
> >     As per RFC 4379, this process includes preservation of the
> original
> > received label stack
> >     and noting the actual ingress interface so that they are
> available
> > for the CP processing.
> 
> [[[Sasha]]] Please note that this is basic MPLS data plane
> functionality that does not depend on configuration of MIPs. Or, if you
> prefer it in a different way, a per-node MIP is by default enabled in
> any MPLS node.

[Maarten] The way you describe this is that a MPLS node which supports
MPLS-TP OAM will have by default Down half-MIP functions on every NNI port.

> If yes, could you please explain how a MIP half-function on an egress
> SDH port is mapped to the ITU-T model of SDH?

[Maarten] When we developed SDH, ATM and OTN, we were not using the MIP/MEP
terminology. This terminology has been introduced when we developed the
Ethernet VLAN OAM as part of the Ethernet transport network developments.

[Maarten] It is however possible to associate the MEP and MIP terms to SDH,
ATM and OTN functions. For the SDH and OTN cases a MIP contains two VC-n NIM
functions (i.e. SDH: Sn_TT_Sk, OTN: ODUkP_TT_Sk and ODUkT_TT_Sk), while a
half MIP contains one NIM function. For ATM a VC MIP contains two sets of
VCM_TT, VCSM_TT and VCLB functions, while a half MIP contains one set.
Similar for VP MIP. 

[Maarten] An egress half MIP in SDH contains one VC-n NIM function, which
monitors the VC-n signal coming from the VC-n switch fabric. An ingress half
MIP in SDH contains one VC-n NIM function, which monitors the VC-n signal
coming from the STM-N NNI port.

> If the model does not support this kind of MIP, the problem is with the

[Maarten] On one hand the functional model is used to describe the
requirements which a node has to support, and on the other hand the
functional model is used to describe the provided behaviour of a node. In
the first usage, the functional model describes the requirements, which the
implementation has to support; how these requirements expressed by means of
the functional model are supported is equipment specific.

[Maarten] If a node supports a per-node MIP function, then the functional
model of this node will include Down half-MIP functions on all its NNI
ports. 
If the functional model presented by an operator includes Down half-MIP
functions on every NNI port, the vendor's implementation complies with the
operator's requirement. For the case the operator requires per-interface MIP
functions on every NNI port (i.e. Down plus Up half-MIP functions on every
port), the vendor's implementation does not comply with the operator's
requirement.

[Maarten] The functional model allows every vendor to describe the provided
behaviour, and every operator to specify the required behaviour. A vendor
will have a problem if his provided behaviour is not supporting the
operator's required behaviour. An operator will have a problem if he/she
can't find a vendor which has equipment that supports the required
behaviour. Typically, the probability that the latter occurs is less than
the probability that the former occurs.

> What is going to happen to Fabric-less implementations?

[Maarten] The switch fabric in the functional model is represented by the
Connection function. As soon as there is flexibility in a node, such
Connection function is present. The implementation of a Connection function
can be manifold; e.g. a centralized switch fabric, a distributed switch
fabric (e.g. port cards + backplane), a flexible labelling process in a
small system-on-chip node, etc.

[Maarten] Connection functions can have very restricted functionality (e.g.
make P2P connections between one line port and a set of trib ports), or have
very extensive functionality (support n-port (n>=2) connections between many
ports, support SNCP, support CL-SNCGP, support SRP, support SMP, support two
or more levels of protection (in dual node interconnect scenarios), etc.

> which lists all specific deviations from the IP/MPLS data plane that
> MPLS-TP introduces, does not list any such as well.
> What's more, PW labels MUST be allocated from the per-platform label
> space (as per RFC 4447) and, AFAIK, are accepted on all MPLS-enabled
> physical ports in most (if not all)implementations. And RFC 5690
> explicitly states that it does not specify any deviations for the PW
> data plane for MPLS-TP.

[Maarten] Ingress filtering of labels on ports is a very important
requirement in transport networks. It is one of the major security measures
in transport networks. Ingress label filtering closes ports for intruders.
It is no problem to allocate per-platform labels as long as each ingress
port performs ingress filtering and discards all packets of which the label
value is not registered on the ingress port.

[Maarten] As an example look at the basic VLAN ID (vlan label) allocation in
802.1Q; vlan labels were per platform labels, and the "Enable Ingress
Filtering" parameter is available to prevent that frames with unexpected
(unregistered) vlan labels (VIDs) could enter the port. Note that this
method is being complemented/replaced at the moment by an extension of the
VLAN ID Translation functionality in individual ingress ports. These ingress
VLAN ID Translation tables will be able to set (as default) the internal
vlan label (R-VID) value to 'FFF' (i.e. discard) for each external vlan
label (VID); e.g. VID=20 => RVID=FFF will discard frames with VLAN ID value
20, and VID=30 => RVID=75 will pass through frames with VLAN ID value 30.

[Maarten] MPLS-TP must have a similar ingress label filtering mechanism ,
otherwise one of the basic transport security methods is not supported. This
is as such a RED flag for MPLS-TP in my opinion.

Regards,
Maarten

> 
> >     b) A per-interface MIP is enabled for this LSP on one interface
> and
> > disabled on another one?
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 23 Nov 2010 16:32:47 +0200

Italo,
In this message I will only refer to the SPME issue (which I am raising as the IETF LC comment on the MPLS-TP FW draft).
I have added Dave Allan (your co-editor) to the CC list.

This is how I see the situation after reading your email:

1. I have, some time ago, raised a technical issue with the proposed SPME concept, namely that the results of
   SPME monitoring are not necessarily correlated with the behavior of traffic in the original monitored LSP.
   My original comment has been discussed on the MPLS-TP mailing list for some time.
2. In your email you agree that this issue is real, and even refer to some individual drafts
   that have raised the same issue.
3. Nevertheless, you, as the co-editor of the draft, retain the SPME concept "as is" in the WG document now in the
   final round IESG discussions before approval for publication as an RFC. And the current version
   of the draft, while discussing some specific aspects of SPME, completely ignores a known issue with SPME.

I do not think that it is reasonable to expect that the target audience of the RFC-to-be has followed the discussion of the draft on this mailing list, or read some individual submissions dealing with one of the concepts introduced in the draft (and which are not even referenced in the draft). Hence, IMHO and FWIW, if the draft were approved for publication as an RFC "as is", it would be misleading its target audience regarding actual usefulness of SPME.

I see two possibilities for resolving the issue:

1. You can withdraw the current SPME concept from the draft. Whether you replace it with another solution for the
   problem or not SPME is supposed to solve or not, is not so relevant at the moment.
2. You retain the current SPME concept but add clarifications and caveats pertaining to the issue raised.
   By doing that you transfer the responsibility for using this concept and dealing with the potentially
   useless results to the operators.

Hopefully these notes clarify my position on the subject.

Regards,
     Sasha

-----Original Message-----
From: BUSI, ITALO (ITALO) [mailto:[email-masked]]
Sent: Monday, November 22, 2010 8:06 PM
To: Alexander Vainshtein; Maarten Vissers
Cc: [email-masked]
Subject: R: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

Thanks, Italo

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 23 Nov 2010 16:06:24 +0100

Sasha,

The SPME has been defined in RFC5921.
The problem has therefore to be resolved within the scope of RFC5921 in my
opinion.

Regards,
Maarten

> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: 23 November 2010 15:33
> To: BUSI, ITALO (ITALO)
> Cc: [email-masked]; Maarten Vissers; [email-masked]
> In this message I will only refer to the SPME issue (which I am raising
> as the IETF LC comment on the MPLS-TP FW draft).
> 3. Nevertheless, you, as the co-editor of the draft, retain the SPME
> concept "as is" in the WG document now in the
>    of the draft, while discussing some specific aspects of SPME,
> completely ignores a known issue with SPME.
> 
> I do not think that it is reasonable to expect that the target audience
> of the RFC-to-be has followed the discussion of the draft on this
> mailing list, or read some individual submissions dealing with one of
> the concepts introduced in the draft (and which are not even referenced
> in the draft). Hence, IMHO and FWIW, if the draft were approved for
> publication as an RFC "as is", it would be misleading its target
> audience regarding actual usefulness of SPME.
> 
> 1. You can withdraw the current SPME concept from the draft. Whether
> you replace it with another solution for the
> > I will snip the fragments where we seem to be in agreement in hope
> that
> > this will improve readability.
> >
> > Regards,
> >      Sasha
> >
> >
> > > Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-
> TP
> > > networks
> > >
> > > Italo,
> > > I will look up my archives and resend the specific comment
> regarding
> > > SPME.
> [ib] I think there is not disagreement here: see section 3.8 of the OAM
> Framework well as draft-koike-mpls-tp-temporal-hitless-psm and draft-
> zhang-mpls-tp-path-segment-monitoring.
> 
> [ib] I am less familiar with the MIP/MEP Map draft but when I read it I
> understood it to be aligned with the OAM Framework.
> 
> > [maarten] in nodes with and without control plane these OAM packets
> have
> > to
> functionality
> [ib] I think that neither the OAM Framework nor the MIP/MEP Map
> precludes the implementation of per-node MIPs. However, they allow also
> the implementation of per-interface MIPs.
> 
> > equipment. The ITU-T functional models provide an unambiguous
> requirement
> > of
> SDH
> > > 3. Taking (1) and (2) above as given, could you please clarify,
> what
> > > exactly does it mean if:
> > If the model does not support this kind of MIP, the problem is with
> the
> > model IMO.
> >
> > [maarten] The PW/LSP is set up over ports A and B. Those Down half-
> MIP
> > functions are
> > able to accept e.g. loopback requests that arrive via the physical
> port,
> > and
> [ib] According to section 3.4 of the OAM Framework, a per-node MIP is
> located in an unspecified location within the node. What Maarten
> describes is the way we can model such a MIP using the ITU-T functional
> components.
> In any case, the conclusion is the same: when a per-node MIP is
> disabled, all OAM packets addressed to it are discarded.
> 
> > are able to accept e.g. loopback requests that arrive via the
> physical
> > port,
> MPLS-
> space
> [ib] Please refer to Errata 2534. However, this is a MAY, so the
> problem you raise can happen (I guess you are considering the case the
> OAM packet is addressed to the per-interface MIP at the ingress side
> because the one at the egress side can still be addressed).
> In such a case, the per-interface MIP on the ingress side does not
> receive the OAM packet and does not reply. The OAM packet is received
> by the per-interface MIP on the egress side that drops it because it is
> not addressed to it.
> 
> > via NNI ports P and Q in a node. Assume that the per-interface MIP on
> port
> > P
> [ib] In a nutshell, the disabled per-interface MIP is dropping all the
> oAM packets addressed to itself (and not replying to them)
> 
> > Regards,
> > Maarten
> >
> > >
> > >
> > > Regards,
> > >      Sasha
> > >
> > > Subject: R: [mpls-tp] about open discussion about MIP MEP in
> MPLS-TP
> > > networks
> > >
> > > Sasha,
> > >
> > > > Da: [email-masked] [mailto:[email-masked]]
> Per
> > > conto
> > > > di Alexander Vainshtein
> > > > Subject: Re: [mpls-tp] about open discussion about MIP MEP in
> MPLS-TP
> > > > networks
> > > >
> > > > Hi,
> > > >
> > > > > [Alessandro] No, I haven't said that. I said the architecture
> must
> > > > include
> > > > In addition, I believe that the OAM Framework (section 3.4
> already
> > > > includes the

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 23 Nov 2010 18:42:35 +0200

Maarten,
Yes, unfortunately 5921 has defined SPME as a hierarchical LSP.
One possible resolution could be:
- Use Option 2 I've proposed in my email to Italo (i.e., add the appropriate caveats for the SPME concept)
- Define that the draft, once it becomes an RFC, updates 5921.

Another option would be to initiate the process of updating 5921. But this would probably take much more time.

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, November 23, 2010 5:06 PM
To: Alexander Vainshtein; 'BUSI, ITALO (ITALO)'
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

Regards,
Maarten

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Fri, 26 Nov 2010 14:08:28 +0100

Sasha,

>    useless results to the operators.

Actually section 3.8 was added to "add clarifications and caveats pertaining to the issue raised" so I think we have already adopted the solution 2. you proposed above.

The individual drafts I referred to (together with a reference to section 3.8) are discussing detailed requirements and solutions to resolve this problem.

Italo

> Inviato: martedì 23 novembre 2010 15.33
> A: BUSI, ITALO (ITALO)
> In this message I will only refer to the SPME issue (which I am raising as
> the IETF LC comment on the MPLS-TP FW draft).
> I do not think that it is reasonable to expect that the target audience of
> the RFC-to-be has followed the discussion of the draft on this mailing
> list, or read some individual submissions dealing with one of the concepts
> introduced in the draft (and which are not even referenced in the draft).
> Hence, IMHO and FWIW, if the draft were approved for publication as an RFC
> "as is", it would be misleading its target audience regarding actual
> usefulness of SPME.
>
> [ib] I think that neither the OAM Framework nor the MIP/MEP Map precludes
> the implementation of per-node MIPs. However, they allow also the
> implementation of per-interface MIPs.
>
> located in an unspecified location within the node. What Maarten describes
> is the way we can model such a MIP using the ITU-T functional components.
> In any case, the conclusion is the same: when a per-node MIP is disabled,
> all OAM packets addressed to it are discarded.
>
> [ib] Please refer to Errata 2534. However, this is a MAY, so the problem
> you raise can happen (I guess you are considering the case the OAM packet
> is addressed to the per-interface MIP at the ingress side because the one
> at the egress side can still be addressed).
> In such a case, the per-interface MIP on the ingress side does not receive
> the OAM packet and does not reply. The OAM packet is received by the per-
> interface MIP on the egress side that drops it because it is not addressed
> to it.
>
> [ib] In a nutshell, the disabled per-interface MIP is dropping all the oAM
> packets addressed to itself (and not replying to them)
>
> > Regards,
> > Maarten
> >
> > >
> > >
> > > Regards,
> > >      Sasha
> > >
> > > Subject: R: [mpls-tp] about open discussion about MIP MEP in    MPLS-
> TP
> > > networks
> > >
> > > Sasha,
> > >

---

From: David Allan I <[email-masked]>
Date: Fri, 26 Nov 2010 08:52:45 -0500

Joining late in the game... Apologies. Still digesting this rather long set of threads...

I agree that adding an SPME after the fact is an issue. The way MPLS works requires use of SPMEs to be designed in advance, hence the utility of SPMEs is limited. Certainly not as an "after the fact" diagnostic tool. They have utility for business purposes where the SPME MEPs would serve a business/operational domain function. So IMO it is not useless, simply not perfect.

That being said I am uncomfortable mandating redesigning MPLS such that every intermediate node is required to offer MEP functionality at multiple points in a given platform and introducing mulitple maintenance levels per labelled level to something that currently has a rather clean 1:1 correspondence between maintenance levels and label levels, hence the text in the 09 version of the OAM framework acknowlwedges the issue with SPMEs in section 3.2 and discusses the broader issues as a diagnostic tool in section 3.8.

SO the current draft describes the concept as it works and is deployed today, and acknowledges the issues and suggests we may have to go further but does not absolutely require it. So is along the lines of #2 below.

Deprecating how MPLS works today is not consistent with the design mandate we've been working to...

My 2 cents
Dave

-----Original Message-----
From: BUSI, ITALO (ITALO) [mailto:[email-masked]]
Sent: Friday, November 26, 2010 8:08 AM
To: Alexander Vainshtein
Cc: [email-masked]; Maarten Vissers; David Allan I
Subject: R: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

Italo

> In this message I will only refer to the SPME issue (which I am
> raising as the IETF LC comment on the MPLS-TP FW draft).
> I do not think that it is reasonable to expect that the target
> audience of the RFC-to-be has followed the discussion of the draft on
> this mailing list, or read some individual submissions dealing with
> one of the concepts introduced in the draft (and which are not even referenced in the draft).
> Hence, IMHO and FWIW, if the draft were approved for publication as an
> RFC "as is", it would be misleading its target audience regarding
> actual usefulness of SPME.
>
> > that this will improve readability.
> >
> > Regards,
> >      Sasha
> >
> >
> > > MPLS-TP networks
> > > regarding SPME.
> > > But the gist of this comment has been, that SPME is a new LSP, so
> > > that monitoring it does not necessarily say anything about the
> > > original LSP passing thru the segment in question. The simplest
> > > use case demonstrating the difference is a case of incomplete
> > > configuration, when the original LSP has not been configured in
> > > one of the internal nodes of the segment, but SPME was (and vice versa).
> [ib] I think there is not disagreement here: see section 3.8 of the
> OAM Framework well as draft-koike-mpls-tp-temporal-hitless-psm and
> draft- zhang-mpls-tp-path-segment-monitoring.
>
> > > 1. We all agree (or so it seems) that intermediate points of LSPs
> > > and PWs can only be reached due to TTL expiration.
> >
> > [maarten] That is what MPLS experts tell me; so this is the
> > assumption
> for
> > MPLS-TP.
> [ib] I am less familiar with the MIP/MEP Map draft but when I read it
> I understood it to be aligned with the OAM Framework.
>
> > > and sends it to the control plane instead.
> >
> > [maarten] see my previous email. Packet transport network equipment
> > without control plane are required to support MIP functions as well.
> > > available for the CP processing.
> >
> > have to be processed as if the MIP is functionally located on the
> > ingress port.
> > functionality that does not depend on configuration of MIPs. Or, if
> > you prefer it in a different way, a per-node MIP is by default enabled in any MPLS node.
> >
>
> precludes the implementation of per-node MIPs. However, they allow
> also the implementation of per-interface MIPs.
>
> > the functional location of a half-MIP or MIP function in each
> > interface port. Both implementation alternatives must comply with
> > the behaviour specified by the functional model.
> > > what exactly does it mean if:
> > the model IMO.
> > [maarten] The PW/LSP is set up over ports A and B. Those Down
> > half-MIP functions are able to accept e.g. loopback requests that
> > arrive via the physical port, and are unable to accept such requests
> > that arrive via the fabric.
> > [maarten] the 'Down half-MIP function' on a NNI port is disabled,
> > and
> OAM
> describes is the way we can model such a MIP using the ITU-T functional components.
> > physical port, and such requests that arrive via the fabric.
> >
> > [maarten] the 'MIP function' on a NNI port is disabled, and OAM
> > [maarten] MIPs and half-MIPs are bound to Managed Entities (PWs,
> > LSPs, Sections).
> >
> > >     a) An LSP uses labels from the per-platform label stace, and
> > > hence packets associated with this LSP can be received from any interface?
> >
> > associated with a PW or LSP on NNI port X, then reception of a
> > packet
> with
> > [[[Sasha]]] To the best of my understanding this is not how the
> > labels from the per-platform label space are treated in IP/MPLS. And
> > RFC 5960 which lists all specific deviations from the IP/MPLS data
> > plane that
> MPLS-
> > (as per RFC 4447) and, AFAIK, are accepted on all MPLS-enabled
> > explicitly
> states
> > that it does not specify any deviations for the PW data plane for
> > MPLS-
> TP.
> >
>
> by the per- interface MIP on the egress side that drops it because it
> is not addressed to it.
>
> > [maarten] Assume that LSP X with endpoint a (EPa) and z (EPz) is
> > transported via NNI ports P and Q in a node. Assume that the
> > per-interface MIP on
> port
> > P
> > is enabled and on port Q is disabled. This implies that e.g. a LSP
> > loopback OAM packet from EPa or EPz can be looped on NNI port P and
> > can not be looped on NNI port Q.
> >
>
> > > > Oggetto: Re: [mpls-tp] about open discussion about MIP MEP in
> > > > MPLS-
> TP
> > > > networks
> > > >
> > > > Adrian,
> > > > per-interface MIPs that have not been considered (according to
> > > > my
> > > reading)
> > > > in RFC 5654.
> > > >
> > > > I think that, at the very least, the notion of a per-interface
> > > > MIP requires additional clarification. E.g., can you introduce a
> > > > per-
> > > interface
> > > [ib] Could you be more specific about how the label space impacts
> > > the support of per-interface vs per-node MIP?
> > >
> > > > On a more generic level, taking into account that the only way
> > > > to
> > > reach a
> > > framework and we have agreed that every node has MIP(s) and that
> > > the operator can disable them. See the following text extracts
> > > from
> section
> > > 3.4:
> > >
> > > > I believe that I've commented on this concept earlier, and in
> > > > any
> > > case I
> > > [ib] Could you please re-send your comment? This would help
> > > expediting its resolution as I fear we have missed it. I apologize for that.
> > >
> > > > Regards,
> > > >      Sasha
> > > >
> > > > >> equipment that allows operators to deploy MPLS-TP networks
> > > > >> that follow the "legacy transport network" mode of operation.
> > > > >
> > > > >> people from building and deploying in other modes, and I
> > > > >> can't
> see
> > > > > all the constructs that are required to get the above
> > > > > mentioned
> > > goal
> > > > already includes the function). So I think we are done.
> > > >
> > > > Adrian
> > > >

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 26 Nov 2010 17:12:25 +0200

Italo,
I will re-read Section 3.8 to check if it addresses the issue.
regards,
Sasha________________________________________
From: BUSI, ITALO (ITALO) [[email-masked]]
Sent: Friday, November 26, 2010 3:08 PM
To: Alexander Vainshtein
Cc: [email-masked]; Maarten Vissers; [email-masked]
Subject: R: [mpls-tp] about open discussion about MIP MEP       in      MPLS-TP networks

Sasha,

Italo

> > without

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 26 Nov 2010 21:53:24 +0200

Italo,
I've re-read Section 3.8 of the draft (and also Section 3.6 to which it points). 

IMHO the text of Section 3.8 can be interpreted as a caveat against using temporal SPMEs - if the reader is looking for such a caveat with a magnifying glass. Otherwise the chances that the reader gets the message are slim.

I would suggest the following change for your consideration:

OLD

3.8. Further considerations of enhanced segment monitoring

   Segment monitoring in transport network should meet the
   following network objectives:
   1. The monitoring and maintenance of existing transport paths has to
      be conducted in service without traffic disruption.
   2. The monitored or managed transport path condition has to be
      exactly the same irrespective of any configurations necessary for
      maintenance.
   SPMEs defined in section 3.2 meet the above two objectives, when
   they are pre-configured or pre-instantiated as exemplified in
   section 3.6. However, pre-design and pre-configuration of all
   the considered patterns of SPME are not sometimes preferable in
   real operation due to the burden of design works, a number of
   header consumptions, bandwidth consumption and so on.
   When SPMEs are configured or instantiated after the transport
   path has been created, network objective (1) can be met, but
   network objective (2) cannot be met due to new assignment of
   MPLS labels.
 
NEW

3.8. Further considerations of enhanced segment monitoring

   Functionality of segment monitoring using SPMEs as defined in Section 3.2 above 
   is affected by the relationship between the lifespan of SPME and that of the transport
   entity whose segment is monitored using SPME.

   If the lifespan of SPME contains that of the transport entity (or entities) whose segment is monitored
   by this SPME (or, in other words, the monitored entity always uses an SPME in order to cross the
   monitored segment), then the results of SPME monitoring reflect behavior of traffic passing thru
   the monitored entity. However, if the monitored entity uses SPME only for part of its lifespan, 
   then, generally speaking, the results of SPME monitoring are not necessarily correlated
   with the behavior of traffic in the monitored entity when it does not use SPME. 

   E.g., application of SPME to a problematic/faulty monitoring entity is apt to "fix" the problem
   encountered by the latter - for as long as SPME is applied. And vice versa, application of
   SPME to a faultless monitored entity may result in in making it faulty - again, as long
   as SPME is applied. These effects stem from the fact that application and removal of SPME
   result in using a different set of cross-connects between incoming and outgoing LSP labels when
   compared to the original state of the monitored entity.

   At the same time application and removal of SPME to a faultless monitored transport entity
   can be performed in such a way as not to introduce any loss of traffic, e.g., by using "make
   before break" technique.

END

Hopefully this proposal would be acceptable to you.

My 2c,
     Sasha

Sent: Friday, November 26, 2010 5:12 PM

Italo,

Sasha,

Italo