Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and notification of lock

[Huub van Helvoort <[e-mail]>]

Hi Nurit,

> You say " this requires that a MIP has the capability to send OAM
> messages based on management command or based on an indication of a MEP
> in a different layer. This also requires that at every MEP location
> there are also MIPs for every client entity serviced by that MEP."

Yes, it was a response to your:
 > BUT the client is not necessarily an
 > endpoint but may be an intermediate point, and it needs to notify its
 > endpoints, that means that a MIP generates an OAM message.

This is the disadvantage of top-posting. All your replies are
out of context and very difficult to follow.

> This looks more as an implementation description. What is actually
> required is that the endpoints of the client layer are informed of this
> event. 

Agreed.

> The way you describe it seems a little bit "against" the framework in
> which it is specified that OAM messages cannot be initiated by MIPs.

Due to the top-posting you reversed the meaning of my description.

It is my opinion (which is in line with current standards) that a
MIP *cannot* initiate OAM messages.

> That is why we actually say that this is an adaptation function, that
> means that the message is initiated by the MEP of the server to the MEP
> of the client.......

That is why I answered that I agree with Italo, who said the same......
(read my reply below).

Regards, Huub.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of ext Huub van
> Helvoort
> Sent: Monday, May 04, 2009 10:27 AM
> To: [e-mail]
> Subject: Re: [Mpls-interop] MPLS-TP OAM requirements - Lock and
> notification of lock
> 
> Hello Nurit,
> 
> You wrote:
> 
>> To continue with the othe rquestion:
>>
>>> See also my e-mail:
>>> MPLS-TP OAM requirements - AIS/LockNotif - Can MIPs send "usolicited"
> 
>>> OAM messages ?
>> The answer was no.
>>
>>> -question:
>>> More generally to the comment above, who should notify and who should
>>> notify whom?
>>> I would tend to say:
>>> the receiving node of a locked direction, informs downstream
> receiving
>>> nodes of nested LSPs. 
>> To be more exact, the sink side of a locked LSP, PW, Section, has to
>> inform its clients.
> 
> You say " To be more exact, the sink side of a locked LSP, PW, Section,
> has to inform its clients.",
> 
> [hvh] it should inform its client transport entities in the
> server/client relation
> 
> BUT the client is not necessarily an
> endpoint but may be an intermediate point, and it needs to notify its
> endpoints, that means that a MIP generates an OAM message.
> 
> [hvh this requires that a MIP has the capability to
> send OAM messages based on management command or based on
> an indication of a MEP in a different layer.
> This also requires that at every MEP location there are also
> MIPs for every client entity serviced by that MEP.
> 
> Long ago I discussed this point with Italo and he indicated to me that
> it is not a generation of a message by a MIP BUT it is a variation of an
> adaptation function at the client intermediate point. Although we are
> talking here about a way to implement it, this is a conceptual issue
> that we need to agree on.
> 
> [hvh] I agree with Italo.
> 
> Also, I think we should generalize the discussion instead of talking
> every time about LSP, PW, section, etc. we should really talk about
> client/server layers to cover cases of LSP hierarchies, etc.
> 
> [hvh] then I use server/client path/trail the next time, OK?
> 
> Regards, Huub.
> 
>>> This is a Fowrward Indication and if we do
>>> so then receiving points MUST indeed be informed of a Lock (c.f.
>>> discussion at the beginning of the e-mail).
>>> Should source points (locking points) do some reverse indication and
>>> notify the source points of the LSPs that are nested in the locked
>> LSP?
>>> (but this maybe falls in the RDI functionality).
>> Isn't this notification already caused by the locking at the
>> far end?
>> Or is the locking only applied in one direction of a bi-directional
>> path? If yes, then the notification is not required.
>>
>> Cheers, Huub.
>>
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...