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

[Yoshinori KOIKE <[e-mail]>]

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