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

[Yoshinori KOIKE <[e-mail]>]

Maarten,

I'm sorry for the confusion.

I meant general aspects of packet transport
network. For example, every frame is monitored/checked
by overhead in SDH/OTN network, while data frames
themselves are not monitored/checked in MPLS-TP, ATM,
Ethernet(other than FCS) network.

Best regards,

Yoshinori

Maarten Vissers wrote:
> 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
> 


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