Subject: [Mpls-interop] MPLS-TP OAM Framework

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 6 Oct 2008 11:08:11 +0200

In attachment the current draft for MPLS-TP OAM Framework for your
review and comments.

We are still reviewing and improving it during this week and we plan to
send an updated version before the MEAD meeting starts.

Thanks, Italo
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Oct 2008 13:08:16 +0100

Thanks Italo,

Random thoughts and nits...

===
Abstract
   "In this regard, it is similar to existing SONET/SDH
  and OTH OAM mechanisms."
I don't see the value of this sentence which is also a non sequita from the 
previous sentence.
===
Abstract
You will need to expand all acronyms in the Abstract.
===
Section 1
  "In this regard, it is similar to existing SONET/SDH
   and OTH OAM mechanisms (e.g. [G.707])."
I don't think this sentence adds to the understanding of the document, and 
it is a non sequita from the previous sentence. Further, "similar" is 
sufficiently vague to be unhelpful.
===
Section 1. Editor's note.
Looks like you have applied this already.
===
Section 1.1 is unnecessary given the "Authors' Addresses" section.
===
Section 1.3
I wonder about the value of defining "tandem connection" in this way. It 
feels like a divergence from G.707 where the tandem connection implies a 
containment relationship along a segment of the end-to-end path. Wouldn't it 
be considerably better to break with the legacy terminology inherited from a 
disimilar technology, and simply refer to "segments".
We can then have "segment monitoring" etc.
===
Section 2
s/in order to bound/in order to bind/
===
Section 2.1
s/in order to bound/in order to bind/
===
Section 2.1
The use of "sub-network" in an IETF document is not really advisable because 
it has another specific meaning.
You have made this observation yourself in seciton 3.
===
Section 2.1
   "As a Maintenance Entity, the End-points at the
    boundary of a tandem connection are MEPs."
I suspect I am missing some meaning here!
Are you trying to say that "If a segment is operated as an ME, then the end 
points of the segment are MEPs."?
===
Section 2.1
  "OAM entities can be nested but not overlapped"
Although you have an editor's note to explain this further, I think some 
more discussion is needed now. It looks to me that you are arbitrarily (or 
because of a view of implementation?) preventing a reasonable function that 
would other wise be made possible by the definition of MEPs and MIPs. I 
think that some of this may be inherited from the containment relationship 
implicit in tandem connections in TDM that does not appear to be present in 
your definition of tandem connection in this document.
Consider, for example, a MSPW that runs T-PE1:S-PE2:S-PE3:T-PE4
Your text syas that you cannot run two MEs as
1. T-PE1 to S-PE3
2. S-PE2 to T-PE4
I can see why the implementation might prevent you from doing this in some 
technologies, but I do not see why this mode of operation is arbitrarily 
restricted before any solution has been designed.
===
Section 2.1
  "OAM packets are subject to the same forwarding
   treatment as the data traffic, but they are
   distinct from the data traffic."
"same" and "distinct" are ambiguous here.
Perhaps you mean "can be distinguished from the data traffic"
===
Section 2.2
You have
  "A MEP prevents OAM packets corresponding to a ME
   from leaking outside that ME."
and the note
   [Editor's note - It is needed to describe about
   how this is achieved. For example, if I have a
   misconnectivity defect causing leaking traffic
   how can the MEP ensure that OAM packets are not
   leaked? Is this description in the scope of this
   document?]
You're quite right. The MEP cannot act as described in the text.
The text might usefully be replaced with...
  A MEP terminates the OAM packets that it receives
  corresponding to its ME and does not forward them
  further along the path.
You need to add another section to the document to describe how nodes handle 
OAM packets that they receive outside the ME for which the packet was 
intended.
===
Section 2.2
  "A MEP allows OAM packets from outside MEs belonging
   to higher (client) layer networks to pass
   transparently"
If there is a hierarchical relationship of MEs, I don't think it is helpful 
to nail that relationship to layer networks. This certainly does not seem to 
fit well with your revised definition of tandem connections.
===
Section 2.2
  "A MEP of an MPLS-TP network transport path
   terminates that transport path..."
I don't think the MEP terminates the path. It is coincident with the end 
point of the path.
===
Section 2.3
It would be helpful to give some examples of the "reactions" that a MIP may 
have to an OAM packet.
===
Section 2.3
Stongly implicit in your text is that a MIP belongs to only one ME. Is this 
the implication you wished to convey? If so, maybe say it explicitly. If 
not, you need to fix up the text.
===
Section 2.3
I think it would be helpfull to clarify that it is not required that each 
LSR between a pair of MEPs is a MIP. That is, that LSRs can be unaware of 
the OAM processes active on the LSPs that they serve.
This point sort of shows up in section 4.1 and comes as a bit of a surprise. 
It should form a key part of the architecture.
===
Section 2.4
Isn't what you need to say that the server ME is completely transparent to 
the ME in a higher layer, but that the server MEPs MAY report fault 
information to the client ME.
Actually, although the mechanisms for such notification is out of scope, you 
do need to point out that the server MEP may be a MEP or a MIP in the client 
(MPLS-TP) network
I don't think it is helpful to provide a proscriptive list of server MEPs. 
Can you chnage this to be examples?
===
Section 3
  " A Section Maintenance Entity (SME), allowing
   monitoring and management of MPLS-TP Sections
   (between MPLS LSRs)."
Do you intend to mean that the LSRs are "adjacent in the LSP"?
Or is the definition of Section more generic to mean any pair of LSRs in the 
LSP?
===
Section 3
As before, I think that the use of the term "tandem conneciton" is not 
helpful in this context since you intend to support the application of OAM 
to an arbitrary LSP or PW segment without any implication of containment.
===
Section 3
Can I ask why we need these multiple definitions?
SME and LME/PME are just special cases of TLME/TPME.
Can't we just be clean and abstract? Define TLME and TPME. Then point out 
that the definition includes single hop and end-to-end cases.

Also, why do you not draw out the difference between SLME and SPME since you 
do not mention the case of OAM on a single PW segment.

By the way, "span" is already used for the concept you introduce as 
"section".
===
Section 3.1
Following on from the previous point, I think you have allowed yourself to 
be confused between server layer OAM and SEM.
SEM operates at the MPLS-TP layer and is unware (as is the data!) of the 
underlying transport. Thus, SEM in a LAG environment may not be fully useful 
because the data may follow multiple paths in the underlying layer, and you 
cannot determine which path the OAM will follow.
This is OK!
You should not try to diagnose the underlying transport layer in the MPLS-TP 
layer. You should run OAM in the transport layer and have it report issues 
to the MPLS-TP layer.
This disctinction is actually quite important!
===
Section 4.1.1
  "Protection Switching: in order to achieve sub-50ms
   recovery time the default transmission period is
   3.33ms (i.e. transmission rate of 300 packets/second)
   although a transmission period of 10ms can also be
   used. In some cases, when a slower recovery time is
   acceptable, it is also possible to relax the
   transmission period."
This text is quite amusing.
You simply cannot say that a timer value must be set to 3.33ms, and then (in 
the same sentence) say that you could se 10ms. Further, you then go on to 
say that the transmission period can be relaxed "in some cases".
Can't you turn this into something more fomulaic? Given a desired switching 
time of Xms, and a hardware switching time of Yms, and an OAM message 
propagation time of Zms, the transmission period should be set to no greater 
than

t = (X-Y-Z)/n

assuming that switchover will not be triggered until n proteciton switching 
messages have failed to be received.

If you then want to give examples, of real numbers that would be fine.

BTW: how do the two MEPs agree on the time values in use?
===
Your references are in a bit of a mess :-)
===
In general, there seems to be a lot of text and concepts inherited without 
explanation from other sources. I'm not sure that any of this adds value 
except as a comforter to readers from other places. For example, in section 
2.1 we have "MPLS-TP layer network": but no indication of what this is 
supposed to mean to the reader. Further, the use of "layer network" implies 
that the hierarchical relationship of MEs is directly associated with a 
network layer hierarchy - I don't know whether we want or need such a 
layering relationship with the implication of label stacking. on the other 
hand, section 2.4 clearly intends the layering concept to include technology 
layers. I suggest you look through the use of "layer network" to decide 
which ones are are really network layers, and which ones are just ME 
relationships.

Cheers,
Adrian

----- Original Message ----- 
From: "BUSI ITALO" <[email-masked]>
To: <[email-masked]>
Sent: Monday, October 06, 2008 10:08 AM
Subject: [Mpls-interop] MPLS-TP OAM Framework

Thanks, Italo

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 06 Oct 2008 16:53:40 +0100

Colleagues,

See attached for the latest version of the MPLS-TP requirements draft as
input to the MEAD meeting next week.

No major changes from draft-00 mainly removal of a few requirements that are
covered in more specific requirements drafts (OAM & NM) and incorporation of
comments from various folks.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 10 Oct 2008 16:45:35 +0100

Colleagues,

See attached for the latest update of the MPLS-TP requirements draft as
input to the MEAD meeting next week.

The only changes are some extra requirements coming out of the ring
protection discussion and requirements submitted by ITU.  I think most of
the ring protection requirements are already covered but I added the
additional ones below.

One thing we need to resolve (during the meeting) is the different "weight"
of some of the requirements in general & specific to ring protection, e.g.
1+1 is MAY in general but ITU say it is MUST for ring protection.

Added requirements:
General:
 *  MPLS-TP protection mechanisms MUST support priority logic to negotiate
and accommodate coexisting requests (i.e. multiple requests) for protection
switching (e.g. "administrative" requests and requests due to link/node
failures).

Specific to ring protection:
 *  If optimised mechanisms for ring topologies are supported then they
MUST:

    +  Support switching times within 50 ms (depending on CV rate
configuration) assuming a reference network of a 16 node ring with less than
1200 Km of fiber.

    +  Support the sharing of ring protection bandwidth, both

       A.  When protection switching is not activated, by allowing the
allocation of "best effort" traffic along the ring, depending on the ring
protection bandwidth availability.

       B.  When protection switching is active. by allowing all of the
connections configured to access the ring protection bandwidth, according to
the priority logic defined for coexisting switching events.

    +  Support inter-ring connectivity, in cases where:

       A.  The rings are connected at a single node and no links are shared
between the rings.

       B.  The rings are connected at two nodes and the connecting link is
shared by the rings

Ben

On 06/10/2008 16:53, "Ben Niven-Jenkins" <[email-masked]>
wrote:

> Colleagues,
> 
> See attached for the latest version of the MPLS-TP requirements draft as input
> to the MEAD meeting next week.
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Mon, 13 Oct 2008 14:02:19 +0200

Adrian,

Thanks for your comments. See in line my replies marked with [ib].

Lack of reply means that I have updated the text according to your
proposal.

Italo

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Monday, October 06, 2008 2:08 PM
> To: BUSI ITALO; [email-masked]
> Subject: Re: [Mpls-interop] MPLS-TP OAM Framework
> 
> Thanks Italo,
> 

[ib] The sequita is related to the requirements and the "comprehensive
set of OAM procedures".

> sufficiently vague to be unhelpful.

[ib] See first comment. I think that it helps understanding the
motivation driving the whole work.

> Looks like you have applied this already.

[ib] Thanks, note removed

> Section 1.1 is unnecessary given the "Authors' Addresses" section.

[ib] I am following the instructions given from Loa in his mail
"instruction on how to handle editors and authors inthe MPLS-TP
documents" on 20/06/2008.

> We can then have "segment monitoring" etc.

[ib] The definition needs to be improved (that's why it is marked with
yellow text).

I would like to have a clear understanding of the "segment" concept
within IETF as I am not sure it matches 100% with TCM. Somebody
associates the concept of "segment" with LSP stitching, that is not
necessarily the case in the TCM context. Moreover my understanding is
that segment has a different semantic in LSP and PW contexts.

I would like to discuss this during the meeting in Boston. In the
meanwhile I will add an editor's note to track the issue.

> You have made this observation yourself in seciton 3.

[ib] I have added the same note also here. The question is how to change
the terminology without loosing semantics.

> points of the segment are MEPs."?

[ib] If I understand correctly, in your terminology a segment operated
as an ME is equivalent to a tandem connection. In this case, your
understanding is correct. In the meanwhile (waiting for the resolution
of the TC vs segment terminology issue) I have rephrased as:
"
The end points of a tandem connection are MEPs because the tandem
connection is by definition a Maintenance Entity.
"

> restricted before any solution has been designed.

[ib] My understanding is that the requirement is to have nesting and not
overlapping.

Moreover, my understanding, is that the framework is somehow the first
step of definining a solution. As such, all the work has been driven by
the output of the JWT activity that is considering TCM implementation
done via label stacking.

>   corresponding to its ME and does not forward them

[ib] I think your proposed text is better than the original text. The
pending question is now whether we need to add some details about how
this is achieved.

> OAM packets that they receive outside the ME for which the packet was 

[ib] I think this is intenteded to be described in the paragraph
following this one, although some rephrase is still needed as described
in the editor's notes.

> fit well with your revised definition of tandem connections.

[ib] I agree with your comment. This paragraph needs major rework: I
have added your comment to the existing editor's note.

> I don't think the MEP terminates the path. It is coincident 

[ib] If I understand your comment, you think it is possible to terminate
a path without having a MEP.

I think it could be useful to understand the MEAD view about the
following question I have therefore is: can we assume that there is a
MEP when the path is terminated?

And secondly, what would be the difference between a path termination
point not having a MEP and a MEP path termination point with all OAM
functions disabled?

> It would be helpful to give some examples of the "reactions" 

[ib] I have rephrased as:
"
A MIP can generate OAM packets only in reaction to OAM packets that are
sent on the ME it belongs to.
"

> It should form a key part of the architecture.

[ib] MIPs are unaware of any OAM flows running between MEPs or between
MEPs and other MIPs. MIPs can only receive and process OAM packets
addressed to the MIP itself.

Is this the kind of information you would like to see in this section?

> Or is the definition of Section more generic to mean any pair 

[ib] I propose to discuss this in Boston because I think there is no
common undertanding of what an MPLS Section is. An MPLS section is not
associated to any LSP but to the adjacency between two LSRs.

> to an arbitrary LSP or PW segment without any implication of 

[ib] I disagree. TC is defined to monitor a sub-path of a connection and
TC are required to be nested and not overlapped.

> that the definition includes single hop and end-to-end cases.

[ib] TLME/TPME are not necessarily single hop. TLME/TPME requires
special mechanisms (e.g. label stacking) to be implemented so I think it
is worth differentiating them from e2e LME/PME.

> do not mention the case of OAM on a single PW segment.

[ib] I guess this comment is due to a different view of what an MPLS
Section is. There is just SME and not SLME/SPME.

> By the way, "span" is already used for the concept you introduce as 

[ib] I would like to come with a clear and common understanding of what
a Section is before changing the terminology. I have no problem to use
"span" instead of "section" is they have the same semantic.

> This disctinction is actually quite important!

[ib] I agree: the SME can only monitor the LAG group, as an adjacency at
the MPLS-TP layer, and not each individual components.

> If you then want to give examples, of real numbers that would be fine.

[ib] I have rephrased but I would like to review the new sentence with
you and other protection experts.

> BTW: how do the two MEPs agree on the time values in use?

[ib] In section 4.1 it is written:
"
For statically provisioned connections, the transmission period and the
ME identifier are statically configured at both MEPs. For dynamically
established connections, the transmission period and the ME identifier
are signaled via the control plane.
"

The only open issue is how to handle the case of misconfiguration at the
two ends. One option is to have an auto-negotiation mechanism, another
option is that each MEPs continue to transmit at the configured rate. In
either case, it is required to report the misconfiguration error to the
operator such that he can fix it.

A side question is whether this behavior is par of the requirement,
framework or protocol solution document.

> Your references are in a bit of a mess :-)

[ib] Yes - the whole section needs to be re-written. That was the
semantic of the yellow text.

> which ones are are really network layers, and which ones are just ME 

[ib] I think/assume that the layer network concept is introduced either
in the MPLS-TP requirements or in the MPLS-TP framework document as this
is general and not striclty related to the OAM.

I agree with your last suggestion to review and check whether layer
network is used in some occurrence instead of ME relationships.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 Oct 2008 13:30:22 +0100

Thanks Italo,

I have cut most of this out to just a few small issues...

>> I don't think the MEP terminates the path. It is coincident
>> with the end point of the path.
>
> [ib] If I understand your comment, you think it is possible to
> terminate a path without having a MEP.

That was not really my concern (although it is true if OAM is not applied).

What I was picking at is that the verb "to terminate" is active. The MEP 
does not cause the termination of the path, it exists at the same place as 
the end of the path.

>> Section 2.3
>> It would be helpful to give some examples of the "reactions"
>> that a MIP may have to an OAM packet.
>
>A MIP can generate OAM packets only in reaction to OAM packets
> that are sent on the ME it belongs to.
>"

Ah, this is helpful.

But ;-)

a) In section 2 you have
     A MIP is capable of reacting to some OAM
     messages but does not initiate OAM messages.
   So presumably one of the reactions from a MIP is the initiation of an OAM
   message.
   We need a bit more clean-up.
b) I think we are missing some substance about the behavior of MIPs. This is
   what I was really pushing for.

>> Section 2.3
>> I think it would be helpfull to clarify that it is not
>> required that each LSR between a pair of MEPs
>> is a MIP. That is, that LSRs can be unaware of
>> This point sort of shows up in section 4.1 and comes as a bit
>> of a surprise. It should form a key part of the architecture.
>
> [ib] MIPs are unaware of any OAM flows running between MEPs or
> between MEPs and other MIPs. MIPs can only receive and process
> OAM packets addressed to the MIP itself.
>

Perfect!

Many thanks,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 13 Oct 2008 16:37:32 +0200

Hi,
Please see my comments in-line. <NS>
Best regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext BUSI ITALO
Sent: Monday, October 13, 2008 14:02
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [Mpls-interop] MPLS-TP OAM Framework

Adrian,

Italo

<NS> Please see my previous general comment on TC. I think that LSP
segment refers to a part of a LSP but this is not sufficient to
implement an OAM maintenance entity over it and have the end to end
traffic transmitting via this entity, etc. We need to define a new
architectural entity which is built of the LSP hierarchy construction
but have 1:1 mapping between the end-to-end path and the segment. This
should work for PW and LSPs. 

<NS> Correct

[ib] I think your proposed text is better than the original text. The
pending question is now whether we need to add some details about how
this is achieved.
<NS> I also think so (although I wrote it :-))

[ib] I agree with your comment. This paragraph needs major rework: I
have added your comment to the existing editor's note.
<NS> Still from implementation point of view it is realized by different
network layers (i.e. using label stacking). 

[ib] If I understand your comment, you think it is possible to terminate
a path without having a MEP.
<NS> I agree with Adrian. A MEP may reside at the edges of an end-to-end
transport path. Path termination is done irrespectively whether there is
a MEP or not.

> required that each 
> of a surprise. 

<NS> I agree.

[ib] I disagree. TC is defined to monitor a sub-path of a connection and
TC are required to be nested and not overlapped.
<NS> As I wrote before also in different mails) I think TC is a segment
of a LSP or one or more segments or a PW and this is a fundamental
architectural element of MPSL-TP. TCME may be used to monitor a Tandem
Connection.  We can also define a protection domain to protect against a
failure of Tandem Connection. Please refer to my previous e-mails on
this. I am sure we'll find more usages for TCs than OAM.

[ib] I would like to come with a clear and common understanding of what
a Section is before changing the terminology. I have no problem to use
"span" instead of "section" is they have the same semantic.
<NS> I think they are the same and that is how we called it in the
survivability framework.

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Oct 2008 20:47:35 +0200

Adrian,

See my reply in line marked with [ib2]

Italo 

> Sent: Monday, October 13, 2008 8:30 AM
> To: BUSI ITALO

[ib2] I got the point. I have therefore rephrase the paragraph as:
"
A MEP in a tandem connection is not coincident with the termination of
the MPLS-TP transport path (LSP or PW), though it can monitor its
connectivity (e.g. count packets). A MEP of an MPLS-TP network transport
path is coincident with transport path termination and monitors its
connectivity (e.g. count packets).
"

>    We need a bit more clean-up.

[ib2] I have rephrased as:
"
A MIP is capable of generating OAM messages only in reaction to received
OAM packets.
"

>    what I was really pushing for.

[ib2] I cannot follow you on this point. The specific "reactions" are
dependent from the each OAM function. The key generic behavior we are
trying to capture in this section is that the MIP is a "passive"
component of the architecture.

> > Is this the kind of information you would like to see in 

[ib2] Ok, I did a cut&past from the mail to section 2.3

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Oct 2008 20:47:37 +0200

Nurit,

Thanks for your feedbacks. See my reply in line marked with [ib2].

I have cut text I am not commenting.

Italo 

> should work for PW and LSPs. 

[ib2] I agree in principle. However (see the next reported comment), it
seems to me that Adrian is defining a tandem connection as a segment
operated as a ME.

> network layers (i.e. using label stacking). 

[ib2] From an implementation point of view, TCM is implemented via label
stacking. However from a functional point of view TC belongs to the same
layer network of the e2e path.

> transport path. Path termination is done irrespectively 

[ib2] See my second reply to Adrian.

> <NS> I think they are the same and that is how we called it in the

[ib2] Ok, I have added a note. I think we need to use the same
terminology in all the documents to name the same concept: either span
or section.
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 16 Oct 2008 20:48:13 +0200

In attachment the updated draft including the comments received so far.
Revision bars mark the changes wrt the previous distributed version.

Italo 

> [mailto:[email-masked]] On Behalf Of BUSI ITALO
> Sent: Monday, October 06, 2008 5:08 AM
> To: [email-masked]