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

[Maarten Vissers <[e-mail]>]

Sasha,

See inline..

> -----Original Message-----
> From: Alexander Vainshtein [mailto:[e-mail]]
> Sent: 2 December 2010 15:46
> To: Maarten Vissers
> Cc: [e-mail]; 'Yoshinori KOIKE'
> Subject: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> 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).

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

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

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

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

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

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

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

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

[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

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