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

["Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[e-mail]>]

Huub, 
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."
This looks more as an implementation description. What is actually
required is that the endpoints of the client layer are informed of this
event. 
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.
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.......
Best regards,
NUrit

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

-- 
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop