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

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

Sasha, Yoshinori,

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

Italo

> -----Messaggio originale-----
> Da: Alexander Vainshtein [mailto:[e-mail]]
> Inviato: mercoledì 1 dicembre 2010 11.09
> A: BUSI, ITALO (ITALO)
> Cc: [e-mail]; Yoshinori KOIKE
> Oggetto: RE: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> 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?
> 

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

> Regards,
>      Sasha
> 
> 
> -----Original Message-----
> From: BUSI, ITALO (ITALO) [mailto:[e-mail]]
> Sent: Wednesday, December 01, 2010 11:52 AM
> To: Yoshinori KOIKE; Alexander Vainshtein
> Cc: [e-mail]
> Subject: R: [mpls-tp] about open discussion about MIP MEP in MPLS-TP
> networks
> 
> 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]
> > **************************************