Re: [Mpls-interop] MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited" OAM messages ?

[George Swallow <[e-mail]>]

Huub -

I very much agree with Martin here.

In MPLS-TP the MEG level is not explicit.  It is inferred from the LSP the
OAM is received on.  In typical LSRs, a Server layer down event, e.g. The
failure of a link results in an "Interface Down Event".  When this occurs
all clients of that interface that have registered for the event would be
notified.  Further notification of peer entities is the responsibility of
those clients.

So to me it makes a great deal of sense to have the MEP serving the link
declare that the IF is down, and have the client MIPs be responsible for
sending any needed OAM messages regarding that event.

...George


On 5/4/09 9:43 AM, "Martin Vigoureux" <[e-mail]>
wrote:

> Huub,
> 
> I am merging the two threads as they talk about the same point.
> Please see below.
> 
> regards,
> -m
> 
> Huub van Helvoort a écrit :
>> Hi Martin,
>> 
>> You responded:
>> 
>>> please see in-line.
>> 
>> me too [hvh]
>> 
>>> Huub van Helvoort a écrit :
>>>> Bonsoir Martin,
>>>> 
>>>> You wrote:
>>>> 
>>>>> as part of the discussion on AIS/Lock Notification,
>>>>> the server layer MEPs, detecting a fault/lock condition, should
>>>>> inform (the MEPs of) the client layers relying on that
>>>>> server layer and which are affected by the condition.
>>>>> 
>>>>> However as I understand it is not the MEP (sMEP) of the
>>>>> server layer that sends a notification to the client layers
>>>>> MEPs (cMEP) but the MIP (cMIP) of the client layer which
>>>>> is hosted on the same node than the MEP (sMEP).
>>>>> See the figure below (where the double dashed line is
>>>>> an LSP, and the ~ line represents an LSP nested in the
>>>>> other LSP.
>>>>> 
>>>>> +------+      +------+      +------+      +------+
>>>>> |      |------|      |------| cMIP |~~~~~~| cMEP |
>>>>> |      |      |      |      |  ^   |      |      |
>>>>> |      |      |      |      |  |   |      |      |
>>>>> |      |      |      |      |  |   |      |      |
>>>>> |      |======|      |======| sMEP |      |      |
>>>>> +------+      +------+      +------+      +------+
>>>> 
>>>> I modified the figure to align with what you wrote.
>>> 
>>> [mvx] thx. In fact the double dashed line was already there
>>>       but with quite some spacing between the top and bottom.
>> 
>> [hvh] OK, tI had the impression that the upper line indicated
>> the client path/trail, and the lower the server path/trail
>> 
>>>>> Therefore can MIPs send OAM messages without having priorly received
>>>>> one
>>>>> or did I miss something?
>>>> 
>>>> No, a MIP can only respond to messages it receives from a MEP
>>>> that has the same MEG level, i.e. exists in the same path.
>>>> 
>>>> In your figure the cMIP ignores messages sent by sMEP.
>>> 
>>> but then, how does a Lock condition of the lower LSP
>>> is notified to cMEP?
>> 
>> This is a consequent action performed in the normal
>> adaptation function between server and client layer.
> 
> and you also say (in the other thread):
> [hvh] The definition used in ITU-T is:
> MEG Intermediate Point (MIP) is an intermediate point in a MEG which
> is capable of reacting to some OAM frames. A MIP does not initiate
> OAM frames. A MIP takes no action on the transit packet flows.
> 
> and:
> [hvh] the sink MEP of the server layer should inform the sink MEPs
> of the client layer.
> 
> How can sMEP send any message to cMEP, they do not belong to the same
> Maintenance Entity?
> The only way I see for cMEP to be informed is that cMIP sends the
> message and if so this contradicts the ITU definition because it does
> this, as you say, as a consequent action performed in the normal
> adaptation function between server and client layer (which I read
> as something different from receiving an OAM message).
> 
> 
>> 
>> Best reagrds, Huub.
>> 
> _______________________________________________
> Mpls-interop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-interop