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

[Alexander Vainshtein <[e-mail]>]

Italo,
The current text refers to a temporal SPME using the following: 

"When SPMEs are configured or instantiated after the transport path has been created..." 

but ignores the case when SPME is removed while the transport path still exists.

Simply expanding the current text would clarify that but, IMO, would make the text unreadable: even now the original sentence counts more than 50 words (stopped counting at some moment).

Any ideas as to how this can be resolved?

Regards,
     Sasha





________________________________________
From: BUSI, ITALO (ITALO) [[e-mail]]
Sent: Wednesday, December 01, 2010 11:08 PM
To: Alexander Vainshtein
Cc: [e-mail]; Yoshinori KOIKE
Subject: R: [mpls-tp] about open discussion about MIP   MEP     in      MPLS-TP networks

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