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

From: Yoshinori KOIKE <[email-masked]>
Date: Wed, 01 Dec 2010 18:36:43 +0900

Sasha and Italo,

Sorry to break in on the discussion. However,
I would like to make a few comments on the
proposed new texts from Sasha.

Firstly, I appreciate the texts proposal
for refining the texts in 3.8 of OAM-fwk draft.
Sasha's proposed texts include at least a few
additional and beneficial inputs to reinforce
the necessity of the further consideration of
a new enhanced segment monitoring function.

However, I'm greatly concerned about removing
two network objectives described in 3.8. IMHO,
these two objectives are indispensable to
validate the necessity of further considerations
of enhanced segment monitoring.

It seems very important that the meaning of
"monitoring function" in transport network is
clarified here. In addition, these network
objectives are goals which we aim for when the
enhanced segment monitoring function is considered.
, although I understand all the features in circuit
based transport network can not be applied in packet
transport network.

Regarding second paragraph in the texts proposal,
adding the observation for not only the start of SPME
but also the end of SPME by using the word "lifespan"
seems valuable. However, the expression seems to
leave some ambiguity. In addition, it seems a little
bit difficult for readers to understand the paragraph
in whole.

Regarding third paragraph, I think the case in "vice
versa" is worth being added.

Regarding forth paragraph, just "make before break" is
not enough to meet the network objective (1). "Non-disruptive
MBB" is correct because MBB itself doesn't guarantee
hitless operation.

Thank you for your consideration in advance.

Best regards,

Yoshinori

Alexander Vainshtein wrote:
> 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
> 
> ________________________________________
> From: Alexander Vainshtein
> Sent: Friday, November 26, 2010 5:12 PM
> To: BUSI, ITALO (ITALO)
> Cc: [email-masked]; Maarten Vissers; [email-masked]
> Subject: RE: [mpls-tp] about open discussion about MIP MEP      in      MPLS-TP networks
> 
> 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,
> 
>> 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.
> 
> 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
> 

-- 
**************************************
Yoshinori Koike
Optical Transmission Systems Development Project
First Promotion Project
NTT Network Service Systems Laboratories
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
Telephone: +81 422 59 6723
Facsimile: +81 422 59 3494
Email: [email-masked]
**************************************

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 01 Dec 2010 10:47:53 +0100

Yoshinori,

> based transport network can not be applied in packet

I believe that your statement above is too generic; I believe that not all
features will be supported in MPLS-TP because of opposition/unwillingness to
adapt the existing MPLS interface port functionality. In ATM and Ethernet
TCM can be activated/deactivated without changing the connection (VC, VP,
VLAN).

Regards,
Maarten

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Yoshinori KOIKE
> Sent: 1 December 2010 10:37
> To: Alexander Vainshtein; BUSI, ITALO (ITALO)
> Cc: [email-masked]
> Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> Sasha and Italo,
> 
> > 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.
> >
> > 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
> >
> 
> 
> 
> --
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Wed, 1 Dec 2010 10:51:34 +0100

I share Yoshinori concerns with removing the two network objectives that service providers have identified so far.

However, I think there are some useful considerations in the proposed text from Sasha that it is worth adding to the draft.

I also agree with Yoshinori suggestion to be explicit that MBB technique should be non-disruptive.

I would therefore propose the following changes to section 3.8:

OLD

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

When SPMEs are configured or instantiated after the transport path has
been created, network objective (1) can be met: 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 non-disruptive "make before break" technique.

However, network objective (2) cannot be met due to new assignment of
MPLS labels. As a consequence, generally speaking, the results of SPME
monitoring are not necessarily correlated with the behaviour of traffic in
the monitored entity when it does not use SPME. For example, application
of SPME to a problematic/faulty monitoring entity might "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 making
it faulty - again, as long as SPME is applied.

Is it acceptable to you?

Thanks, Italo

> -----Messaggio originale-----
> Da: Yoshinori KOIKE [mailto:[email-masked]]
> Inviato: mercoledì 1 dicembre 2010 10.37
> A: Alexander Vainshtein; BUSI, ITALO (ITALO)
> Cc: [email-masked]; [email-masked]
> Oggetto: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> Sasha and Italo,
> 
> 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.
> >
> section 3.8) are discussing detailed requirements and solutions to resolve
> this problem.
> >
> > Italo
> >
> 
> 
> 
> --

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 1 Dec 2010 12:00:23 +0200

Yoshinori,
Lots of thanks for an important input.

I do not have any issues with retaining objectives (1) and (2) in the text.
What's more, it seems that these objectives are applicable not just to segment/sub-path monitoring.
I would suggest to consider moving them to a separate section (probably a new one) dealing with non-intrusive OAM in general
(as opposed to intrusive OAM, e.g., loopback) and just referring to them in Section 3.8.
IMHO this would also help to address your concern regarding clarification of the meaning of "monitoring function" in a transport network.

I am also quite open to clarifying the term "lifespan". Any specific suggestions in this regard would be appreciated.
I have used a network diagram (attached for your consideration) to illustrate the problem described in the 2nd paragraph in certain private exchanges. If you think it is helpful, I could try to convert it to "ASCII art" so it can be included in the draft.

I am not sure I follow you regarding the need to add the "vice versa" case in the 3rd paragraph. Could you please elaborate?

I also fully agree that the reference to MBB should be replaced by "non-intrusive MBB". (BTW, I have searched the draft for the term "intrusive", but did not find it.) 

Regards,
     Sasha

-----Original Message-----
From: Yoshinori KOIKE [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 11:37 AM
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 and Italo,

Best regards,

Yoshinori

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 1 Dec 2010 12:09:07 +0200

Italo,
Looks like a step in the right direction to me.

Two comments (I've already sent them in my response to Yoshinori):

1. Don't you think that objectives (1) and (2) apply not just to segment monitoring but also to non-intrusive/non-disruptive monitoring in general? If yes, would you consider moving them to a separate section and referencing them in Section 3.8?

2. As Yoshinori has noted, removal of SPME *before deletion* of the  LSP whose segment it monitors could have the same effect as creation of an SPME after creation of the LSP. I have tried to express it using the term "lifespan", but I am quite open to any proposal that carries the same message, namely that "temporal" SPME is problematic.

Regards,
     Sasha

-----Original Message-----
From: BUSI, ITALO (ITALO) [mailto:[email-masked]] 
Sent: Wednesday, December 01, 2010 11:52 AM
To: Yoshinori KOIKE; Alexander Vainshtein
Cc: [email-masked]
Subject: R: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

OLD

NEW

Is it acceptable to you?

Thanks, Italo

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Wed, 1 Dec 2010 22:08:44 +0100

Sasha, Yoshinori,

Thanks for your help in improving section 3.8. In line my comments marked with [ib]

Italo

> Da: Alexander Vainshtein [mailto:[email-masked]]
> Inviato: mercoledì 1 dicembre 2010 11.09
> A: BUSI, ITALO (ITALO)
> Cc: [email-masked]; Yoshinori KOIKE
> Oggetto: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> Italo,
> 1. Don't you think that objectives (1) and (2) apply not just to segment
> monitoring but also to non-intrusive/non-disruptive monitoring in general?
> If yes, would you consider moving them to a separate section and
> referencing them in Section 3.8?
> 

[ib] I am not very comfortable to restructure the document. What about:

c/Segment monitoring/Segment monitoring, like any in service monitoring,/

> 2. As Yoshinori has noted, removal of SPME *before deletion* of the  LSP
> whose segment it monitors could have the same effect as creation of an
> SPME after creation of the LSP. I have tried to express it using the term
> "lifespan", but I am quite open to any proposal that carries the same
> message, namely that "temporal" SPME is problematic.
> 

[ib] In the latest text proposal, I am avoiding the term "lifespan" but keeping the two examples with the clarification that the different conditions of SPME vs monitored entity are valid as long as the SPME is applied.

[ib] Is the text missing some important piece of information?

> I share Yoshinori concerns with removing the two network objectives that
> service providers have identified so far.
> 
> However, I think there are some useful considerations in the proposed text
> from Sasha that it is worth adding to the draft.
> 
> > > I've re-read Section 3.8 of the draft (and also Section 3.6 to which
> it
> > points).
> > >
> > >    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
> > >    by this SPME (or, in other words, the monitored entity always uses
> an
> > SPME in order to cross the
> > >    the monitored entity. However, if the monitored entity uses SPME
> only
> > for part of its lifespan,
> > >    with the behavior of traffic in the monitored entity when it does
> not
> > use SPME.
> > >
> > >    encountered by the latter - for as long as SPME is applied. And
> vice
> > versa, application of
> > >    as SPME is applied. These effects stem from the fact that
> application
> > and removal of SPME
> > >>    problem or not SPME is supposed to solve or not, is not so
> relevant
> > at
> > >> the moment.
> resolve

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 2 Dec 2010 07:33:00 +0200

Italo,
The current text refers to a temporal SPME using the following: 

"When SPMEs are configured or instantiated after the transport path has been created..." 

but ignores the case when SPME is removed while the transport path still exists.

Simply expanding the current text would clarify that but, IMO, would make the text unreadable: even now the original sentence counts more than 50 words (stopped counting at some moment).

Any ideas as to how this can be resolved?

Regards,
     Sasha

Sent: Wednesday, December 01, 2010 11:08 PM

Sasha, Yoshinori,

Italo

---

From: Yoshinori KOIKE <[email-masked]>
Date: Thu, 02 Dec 2010 20:13:23 +0900

Maarten,

I'm sorry for the confusion.

I meant general aspects of packet transport
network. For example, every frame is monitored/checked
by overhead in SDH/OTN network, while data frames
themselves are not monitored/checked in MPLS-TP, ATM,
Ethernet(other than FCS) network.

Best regards,

Yoshinori

Maarten Vissers wrote:
>> it points).
>> Section 3.2 above
>> that of the transport
>> an SPME in order to cross the
>> only for part of its lifespan,
>> not use SPME.
>> vice versa, application of
>> application and removal of SPME
>> relevant at

---

From: Yoshinori KOIKE <[email-masked]>
Date: Thu, 02 Dec 2010 20:23:20 +0900

Sasha,

Thank you very much for the comments and the material.
Sorry to be late to reply to you. See in line marked
with [YK], please.

 > I do not have any issues with retaining objectives (1) and (2) in the
text.

[YK] Thank you very much for the understanding.

 > I would suggest to consider moving them to a separate section
(probably a new one) dealing with non-intrusive OAM in general
 > IMHO this would also help to address your concern regarding
clarification of the meaning of "monitoring function" in a transport
network.

[YK]I think you are correct regarding the applicability of the
network objectives. However, IMHO, there seems no need to
move the two objectives to other section at the moment. Since
there is no issue in the other parts of the draft, there seems
no substantial utility by moving the place. Rather, I'm worrying
about increasing unnecessary works which are not desirable,
such as finding the best place to put it, changing expressions or
structures based on the change, finding other missing
network objectives and so on.
I prefer to leave the treatment to editors.

 > I am also quite open to clarifying the term "lifespan". Any specific
suggestions in this regard would be appreciated.

[YK] My preference on this topic is also to leave the treatment
to editors. IMHO, the criteria for the judgment whether it should
be reflected depends on how much details of the problem statement
should be described in OAM-FWK draft. I'm not 100% sure the
strictness of the problem statement is required in the document.

As you may know, I'm writing a draft to clarify the problem statement
and requirements on this issue. I'm very happy to add and reflect your
comments in next version of the
draft(draft-koike-mpls-tp-temporal-hitless-psm), if you are OK with
that.
https://datatracker.ietf.org/doc/draft-koike-mpls-tp-temporal-hitless-psm/

 > I have used a network diagram (attached for your consideration) to
illustrate the problem described in the 2nd paragraph in certain private
exchanges. If you think it is helpful, I could try to convert it to
"ASCII art" so it can be included in the draft.

[YK]Thank you very much for the material. Actually I already
explained the similar figure in IETF79. You can find it in the
following URL. I'll reflect this in the next version of my draft.
http://tools.ietf.org/agenda/79/slides/mpls-12.ppt#271,7,Potential issue
of SPME
However, I would like consider your diagram in next version of my
individual draft, if you are ok with that.

 > I am not sure I follow you regarding the need to add the "vice versa"
case in the 3rd paragraph. Could you please elaborate?

[YK]I meant that it is also useful to introduce that there is
also a possibility that enabling/setting SPME can cause some
fault/defect on the monitored transport path which haven't
had any fault/defect.

 > I also fully agree that the reference to MBB should be replaced by
"non-intrusive MBB". (BTW, I have searched the draft for the term
"intrusive", but did not find it.)

[YK] Actually, I used the term "non-disruptive" I meant
"without service disruption" in general meaning. However,
if we use the "non-intrusive", the meaning seems a little
different from my original intention. In my understanding,
"intrusive" (by breaking the original trail) is the term
used during the measurement/monitoring, not used when the
monitoring function/segment is manually configured. Therefore,
non-disruptive(or non-service-disruptive) seems appropriate
in this case.

Best regards,

Yoshinori

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 02 Dec 2010 15:01:47 +0100

Yoshinori,

Thanks for your clarification. Let me provide some further considerations on
the commonality between circuit and packet technologies:

SDH monitors every RSn, MSn, HOVC and LOVC frame and OTN monitors every OPU
frame by means of a BIP-N (a BIP-N is a specific form of CRC). SDH and OTN
do not discard frames with one or more detected bit errors.

Every MPLS-TP and Ethernet frame is monitored by means of a FCS (e.g. MAC
FCS, GFP FCS) (FCS is a specific form of CRC), plus the number of MPLS-TP or
Ethernet frames transmitted is counted and the number of frames received is
counted. Frames with a FCS error are discarded by MPLS-TP and Ethernet; the
counting of the number of frames transmitted/received at the MEPs represents
the errors detected.

Every ATM cell information field is monitored by means of a BIP-16 computed
over a set of user cells. In addition, every ATM cell header is monitored by
means of a HEC.

As far as I can see, all frames in SDH, OTN, ATM, MPLS-TP and Ethernet are
monitored/checked by overhead/OAM. So there is no *basic* difference between
the monitoring of those technologies. Do you agree?

The difference is the treatment of frames with a bit error; in SDH and OTN
those errored frames are forwarded, in MPLS-TP and Ethernet those errored
frames are discarded. The discarding of those errored frames carries the
error indication towards the far end MEP, which can detect the number of
errored (and consequently discarded) frames by comparing transmitted and
received frame counts.

The other OAM/Overhead in circuit and packet networks does not monitor the
frames passed through the connection. This other OAM/Overhead monitors the
connection (within which the frames are forwarded), and it does not matter
if this OAM/overhead is carried in separate OAM frames or in Overhead
bits/bytes of frames that also carry user data.

This very strong connection related commonality is underlying the ability to
use the same OAM tools in any transport network technology.

Regards,
Maarten

> Sent: 2 December 2010 12:13
> To: Maarten Vissers
> Cc: 'Alexander Vainshtein'; 'BUSI, ITALO (ITALO)'; [email-masked];
> [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 2 Dec 2010 16:45:42 +0200

Maarten,
Please see some comments inline below.

Regards,
     Sasha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Thursday, December 02, 2010 4:02 PM
To: 'Yoshinori KOIKE'
Cc: [email-masked]
Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Yoshinori,

Every MPLS-TP and Ethernet frame is monitored by means of a FCS (e.g. MAC
FCS, GFP FCS) (FCS is a specific form of CRC),

[[[Sasha]]] This is simply not true for MPLS (TP or not TP). MPLS does not have any CRC
(or any other form of data integrity check) of its own. This functionality is left
for the data link layer (Ethernet, HDLC, ATM AAL5 or GFP - take your choice).

plus the number of MPLS-TP or Ethernet frames transmitted is counted and the number of frames received is
counted. 
 [[[Sasha]]] This count is local (i.e., you cannot compare packets received via 
a certain ports with the packets that have been transmitted to from the peer port in the adjacent box.
If you want such a comparison, you have equipment that supports this functionality (today it is not
supported as a rule) and you also have to explicitly enable it.
This is fundamentally different from SDH the number of frames per second is well know at every level,
and BIP (which, BTW, is not similar to CEC) is an inherent part of every frame.

Frames with a FCS error are discarded by MPLS-TP and Ethernet; the
counting of the number of frames transmitted/received at the MEPs represents
the errors detected.

[[[Sasha]]] Please see above. 

Every ATM cell information field is monitored by means of a BIP-16 computed
over a set of user cells. 

[[[Sasha]]] What? I suggest you look up AAL1 and AAL5 specifications. The former does not provide
any means whatsoever for checking integrity of the user data, and the latter uses CRC-32.
BTW, both are ITU-T specs.

In addition, every ATM cell header is monitored by 
means of a HEC.[[[Sasha]]]  This is completely irrelevant for the discussion.

[[[Sasha]]] As you can guess, I disagree, and I think that you are factually wrong.

[[[Sasha]]] Let's start from the fact that in packet (and, BTW, ATM) networks, frames are discarded not only due 
To bit errors, but also (and mainly) due to congestion. Congestion does not have any analog in SDH.
In addition, indication of frames discarded due to CRC errors happens only at the data link layer
(which MPLS-TP is not), and its indications are not forwarded anywhere.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 02 Dec 2010 16:32:23 +0100

Sasha,

See inline..

> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: 2 December 2010 15:46
> To: Maarten Vissers
> Cc: [email-masked]; 'Yoshinori KOIKE'
> Behalf Of Maarten Vissers

[maarten] I did not say that MPLS(TP) has a CRC of its own. But it is true
that every MPLS packet is monitored for bit errors when travelling over a
link. That is what I was indicating.

> and BIP (which, BTW, is not similar to CEC) is an inherent part of

[maarten] The two counts and the computed difference give it a connection
scope (i.e. not just local). And as we are discussing MPLS-TP including the
packet loss monitoring OAM, we can assume that MPLS-TP equipment supports
this. MPLS equipment does not support it, and that is why I used MPLS-TP. In
SDH equipment you have to configure the error monitoring, otherwise the BIP
functionality is simply ignored. In MPLS-TP you will have to configure the
loss monitoring, otherwise the packet loss information is simply ignored. No
difference as such.

[maarten] For the frame monitoring it is not important if the frame rate is
fixed or variable. A fixed frame rate is just a corner case of the variable
rate case.

> BTW, both are ITU-T specs.

[maarten] I am referring to I.610 ATM VP and VC FPM OAM.

> [[[Sasha]]] As you can guess, I disagree, and I think that you are

[maarten] I believe we have different opinions/understandings.

> [[[Sasha]]] Let's start from the fact that in packet (and, BTW, ATM)
> networks, frames are discarded not only due

[maarten] I am very much aware of the discarding due to congestion. I am
also aware that in transport networks the expectation is that such
discarding will be rare conditions for the non-drop eligible frames. 

[maarten] The counting of transmitted and received frames and the
computation of the difference presents the number of non-drop eligible
frames that have been lost due to bit errors on the links and congestion on
the links. The absence of an expected frame is a very good indication of
such loss at an upstream point in the connection. The absence is forwarded
by means of the transmitted and received counts.

I hope this clarifies my view a bit better.
Regards,
Maarten

> > > TCM can be activated/deactivated without changing the connection
> (VC,
> > VP,
> > > VLAN).
> > >
> > > Regards,
> > > Maarten
> > >
> > >> Subject: Re: [mpls-tp] about open discussion about MIP MEP in
> MPLS-
> > TP
> > >> networks
> > >>
> > >> Sasha and Italo,
> > >>

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Dec 2010 08:11:43 -0800

Snipped...

In the context of MPLS-TP what is a 'non-drop eligible frame'?  For one thing, we deal in packets.  For another, within a packet, where is this non-drop eligibility information carried?

Also, what does 'congestion on the links' mean?

Sent from my iPhone

> > To bit errors, but also (and mainly) due to congestion. Congestion
> does
> > not have any analog in SDH.
o/mpls-tp

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 2 Dec 2010 18:22:29 +0200

Maarten,
Lots of thanks for a prompt response.

Looks like neither of us can convince the other... 

Regards,
     Sasha

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]] 
Sent: Thursday, December 02, 2010 5:32 PM
To: Alexander Vainshtein
Cc: [email-masked]; 'Yoshinori KOIKE'
Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP networks

Sasha,

See inline..