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

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

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.
> 

-- 
================================================================
Always remember that you are unique...just like everyone else...