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

["BUSI, ITALO (ITALO)" <[e-mail]>]

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:[e-mail]]
> Inviato: mercoledì 1 dicembre 2010 10.37
> A: Alexander Vainshtein; BUSI, ITALO (ITALO)
> Cc: [e-mail]; [e-mail]
> Oggetto: 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
> 
> 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: [e-mail]; Maarten Vissers; [e-mail]
> > 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) [[e-mail]]
> > Sent: Friday, November 26, 2010 3:08 PM
> > To: Alexander Vainshtein
> > Cc: [e-mail]; Maarten Vissers; [e-mail]
> > 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: [phone]
> Facsimile: [phone]
> Email: [e-mail]
> **************************************