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

[Yoshinori KOIKE <[e-mail]>]

Sasha,

Thank you very much for the comments and the material.
Sorry to be late to reply to you. See in line marked
with [YK], please.

Alexander Vainshtein wrote:
 > Yoshinori,
 > Lots of thanks for an important input.
 >
 > I do not have any issues with retaining objectives (1) and (2) in the
text.

[YK] Thank you very much for the understanding.

 > What's more, it seems that these objectives are applicable not just to
segment/sub-path monitoring.
 > I would suggest to consider moving them to a separate section
(probably a new one) dealing with non-intrusive OAM in general
 > (as opposed to intrusive OAM, e.g., loopback) and just referring to
them in Section 3.8.
 > IMHO this would also help to address your concern regarding
clarification of the meaning of "monitoring function" in a transport
network.

[YK]I think you are correct regarding the applicability of the
network objectives. However, IMHO, there seems no need to
move the two objectives to other section at the moment. Since
there is no issue in the other parts of the draft, there seems
no substantial utility by moving the place. Rather, I'm worrying
about increasing unnecessary works which are not desirable,
such as finding the best place to put it, changing expressions or
structures based on the change, finding other missing
network objectives and so on.
I prefer to leave the treatment to editors.

 > I am also quite open to clarifying the term "lifespan". Any specific
suggestions in this regard would be appreciated.

[YK] My preference on this topic is also to leave the treatment
to editors. IMHO, the criteria for the judgment whether it should
be reflected depends on how much details of the problem statement
should be described in OAM-FWK draft. I'm not 100% sure the
strictness of the problem statement is required in the document.

As you may know, I'm writing a draft to clarify the problem statement
and requirements on this issue. I'm very happy to add and reflect your
comments in next version of the
draft(draft-koike-mpls-tp-temporal-hitless-psm), if you are OK with
that.
https://datatracker.ietf.org/doc/draft-koike-mpls-tp-temporal-hitless-psm/

 > I have used a network diagram (attached for your consideration) to
illustrate the problem described in the 2nd paragraph in certain private
exchanges. If you think it is helpful, I could try to convert it to
"ASCII art" so it can be included in the draft.

[YK]Thank you very much for the material. Actually I already
explained the similar figure in IETF79. You can find it in the
following URL. I'll reflect this in the next version of my draft.
http://tools.ietf.org/agenda/79/slides/mpls-12.ppt#271,7,Potential issue
of SPME
However, I would like consider your diagram in next version of my
individual draft, if you are ok with that.

 > I am not sure I follow you regarding the need to add the "vice versa"
case in the 3rd paragraph. Could you please elaborate?

[YK]I meant that it is also useful to introduce that there is
also a possibility that enabling/setting SPME can cause some
fault/defect on the monitored transport path which haven't
had any fault/defect.

 > I also fully agree that the reference to MBB should be replaced by
"non-intrusive MBB". (BTW, I have searched the draft for the term
"intrusive", but did not find it.)

[YK] Actually, I used the term "non-disruptive" I meant
"without service disruption" in general meaning. However,
if we use the "non-intrusive", the meaning seems a little
different from my original intention. In my understanding,
"intrusive" (by breaking the original trail) is the term
used during the measurement/monitoring, not used when the
monitoring function/segment is manually configured. Therefore,
non-disruptive(or non-service-disruptive) seems appropriate
in this case.

Best regards,

Yoshinori


Alexander Vainshtein wrote:
> Yoshinori,
> Lots of thanks for an important input.
> 
> I do not have any issues with retaining objectives (1) and (2) in the text.
> What's more, it seems that these objectives are applicable not just to segment/sub-path monitoring.
> I would suggest to consider moving them to a separate section (probably a new one) dealing with non-intrusive OAM in general
> (as opposed to intrusive OAM, e.g., loopback) and just referring to them in Section 3.8.
> IMHO this would also help to address your concern regarding clarification of the meaning of "monitoring function" in a transport network.
> 
> I am also quite open to clarifying the term "lifespan". Any specific suggestions in this regard would be appreciated.
> I have used a network diagram (attached for your consideration) to illustrate the problem described in the 2nd paragraph in certain private exchanges. If you think it is helpful, I could try to convert it to "ASCII art" so it can be included in the draft.
> 
> I am not sure I follow you regarding the need to add the "vice versa" case in the 3rd paragraph. Could you please elaborate?
> 
> I also fully agree that the reference to MBB should be replaced by "non-intrusive MBB". (BTW, I have searched the draft for the term "intrusive", but did not find it.) 
> 
> Regards,
>      Sasha
> 
> 
> -----Original Message-----
> From: Yoshinori KOIKE [mailto:[e-mail]] 
> Sent: Wednesday, December 01, 2010 11:37 AM
> To: Alexander Vainshtein; BUSI, ITALO (ITALO)
> Cc: [e-mail]; [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]
**************************************