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

[Alexander Vainshtein <[e-mail]>]

Maarten,
Please see some comments inline below.

Regards,
     Sasha

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

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),

[[[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.

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?

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

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.

[[[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.

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


> -----Original Message-----
> From: Yoshinori KOIKE [mailto:[e-mail]]
> Sent: 2 December 2010 12:13
> To: Maarten Vissers
> Cc: 'Alexander Vainshtein'; 'BUSI, ITALO (ITALO)'; [e-mail];
> [e-mail]
> Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> 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:
> > Yoshinori,
> >
> >> , although I understand all the features in circuit
> >> based transport network can not be applied in packet
> >> transport network.
> >
> > 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Yoshinori KOIKE
> >> Sent: 1 December 2010 10:37
> >> To: Alexander Vainshtein; BUSI, ITALO (ITALO)
> >> Cc: [e-mail]
> >> Subject: Re: [mpls-tp] about open discussion about MIP MEP in MPLS-
> TP
> >> networks
> >>
> >> 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
> >>


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