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

[Maarten Vissers <[e-mail]>]

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


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