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

[Maarten Vissers <[e-mail]>]

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
> 
> 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]
> **************************************
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp