Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport pathrequirements)

From: Huub van Helvoort <[email-masked]>
Date: Mon, 01 Jun 2009 10:30:54 +0200

Hello Nurit,

I don't understand what you mean, my questions are in-line [hvh]:

> In Y.1731, we have a message

[hvh] can you be more specific, which message you refer to (or a
section number in Y.1731).

> that is initiated by the server MEP to the clients MEPs 

[hvh] do you mean inserted by the server sink MEP to the client
sink MEP(s)?

> and is adapted by the clients located at the same NE as the
> server that initiates the message. 

[hvh] what do you mean by "adapted"? is the message changed?

> In a way this involves inter-layer communication (or whatever).

[hvh] are you refering to the processes in the adaptation function
which sits on the border between layers?

> In the proposal below, the local clients (MIPs at the client layer) are
> notified (locally) by the server layer of the fault

[hvh] do you mean that a client MIP is always, i.e. mandatory,
present in the same NE as a sink server MEP?

> and if
> needed/required they may send a notification/alarm to their MEPs
> (communication is initiated and terminated at the same layer).

[hvh] are "they" the MIP(s)? so a MIP will insert a message to the
sink MEP without receiving a message to do so?

> We have an "adaptation" function vs. a "notification" initiated by a MIP
> and sent to the MEP at the same layer.

[hvh] the adaptation function is not a replacement for the MIP,
it has been there from day one (even before MEP and MIP were introduced.
A MIP able to sent autonomously a message is a new concept.

Regards, Huub.

> -----Original Message-----
> From: Heiles, Juergen (NSN - DE/Munich) 
> Sent: Friday, May 29, 2009 10:10 AM
> To: ext Ben Niven-Jenkins; Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod
> HaSharon); Loa Andersson
> Cc: [email-masked]
> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport
> pathrequirements)
> 
> HI Ben,
> 
> as said in my previous email the ITU definitions are correct. The Server
> MEP inserts the notification as the adaptation is part of the server
> MEP. This is the way Y1731 defines it. 
> Under normal conditions (no failure) the adaptation at the server MEP
> extracts the client data (CI) from the server layer. Under server layer
> failure conditions it generates the failure notification for the client
> layer.
> The MIP stays passive and can only monitor. 
> 
> Regards
> 
> Juergen
> 
> 
> 
>> -----Original Message-----
>> From: ext Ben Niven-Jenkins [mailto:[email-masked]] 
>> Sent: Thursday, May 28, 2009 10:38 PM
>> To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); 
>> Loa Andersson; Heiles, Juergen (NSN - DE/Munich)
>> Cc: [email-masked]
>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
>> transport pathrequirements)
>>
>> Do we need to change the definition? What do implementations 
>> of say Y1731
>> which has similar MEP/MIP do in this scenario? Is the 
>> definition in Y1731
>> (MIPs only process & react they don't initiate OAM frames) on which our
>> definition is based wrong, in which case ITU need to fix their 
>> definition.
>> If Y1731 can do it without having MIPs initiate OAM frames then our
>> understanding is wrong.
>>
>> Ben
>>
>>
>>
>> On 28/05/2009 15:04, "Adrian Farrel" <[email-masked]> wrote:
>>
>>> I think this completes the loop, Nurit. Please decrement the TTL.
>>>
>>> We started with "The definition of MIP we have seems to say 
>> cannot initiate
>>> an OAM packet?"
>>>
>>> If the intention is to change the definition of MIP then we 
>> need to find out
>>> how many places we need to change that definition. Is it OK 
>> to say "MPLS-TP
>>> MIP" and mean something else than is meant for a generic 
>> ITU-T MIP? Should
>>> the ITU-T definition of MIP be changed?
>>>
>>> A
>>> ----- Original Message -----
>>> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
>> <[email-masked]>
>>> To: "ext Loa Andersson" <[email-masked]>; "Heiles, Juergen (NSN - 
>> DE/Munich)"
>>> <[email-masked]>
>>> Cc: <[email-masked]>
>>> Sent: Thursday, May 28, 2009 2:26 PM
>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
>> transport
>>> pathrequirements)
>>>
>>>
>>>> Hi,
>>>> Good point Loa regarding the adaptation function, and it 
>> came just when
>>>> I have started writing a new proposal to the WG.
>>>> As defined in the OAM framework, it is only the MEPs that 
>> are allowed to
>>>> initiate messages flow across the maintenance entity. The 
>> MIPs only acts
>>>> as a response to such messages.
>>>> If we look at SNMP for example (and also at the CP), the 
>> manager entity
>>>> is the one that initiates commands ("set") and retrieval messages
>>>> ("get", "get bulk"). The agent entity only responds to 
>> these messages,
>>>> but is allowed also to send traps/notifications to the management
>>>> entity.
>>>> I would like to propose to enhance the functionality of the MIPs and
>>>> allow the MIPs initiating and sending error-notifications 
>> to the MEPs.
>>>> In such a case, when a MIP detects a fault it can send an error
>>>> notification to its MEPs.
>>>> I think that by doing this we keep the architecture clean and do not
>>>> break the layering models but add an important 
>> functionality which can
>>>> enhance the general behavior and provide better functionality.
>>>> Best regards,
>>>> Nurit
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of ext Loa Andersson
>>>> Sent: Thursday, May 28, 2009 4:11 PM
>>>> To: Heiles, Juergen (NSN - DE/Munich)
>>>> Cc: [email-masked]
>>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated 
>> bidirectional transport
>>>> path requirements)
>>>>
>>>> Juergen,
>>>>
>>>> top post only.
>>>>
>>>> This is possibly right, but it rocks some of the 
>> "fundamental truths"
>>>> that I've been trying to understand since the start MPLS-TP project.
>>>>
>>>> What has been said is that OAM is done by groups of functions at the
>>>> end-points of LSPs (connections)- MEPs, and at intermediary points
>>>> of those LSPs - MIPs.
>>>>
>>>> Now there is a suddenly (at least for me) a new entity - an 
>> adaptation
>>>> function - that starts injecting OAM packets on LSPs.
>>>>
>>>> I think I understands this, but it still leaves me with the 
>> problem I
>>>> had to start with. These messages has to direct to packets 
>> to all the
>>>> MEPs at the at the endpoints of the tunneled LSPs, so there 
>> is a unique
>>>> packet going to each MEP.
>>>>
>>>> The time this will take is probably something like 50ms (fault
>>>> detection) + 800 x 5 ms ~ 4s (and consuming all the cycles of the
>>>> nodes at the end of the tunnel. Is this significantly better than
>>>> send information to the NMS.
>>>>
>>>> /Loa
>>>>
>>>> Heiles, Juergen (NSN - DE/Munich) wrote:
>>>>> Hi Loa,
>>>>>
>>>>> see below.
>>>>>
>>>>> Regards
>>>>>
>>>>> Juergen
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ext Loa Andersson [mailto:[email-masked]]
>>>>>> Sent: Wednesday, May 27, 2009 12:17 PM
>>>>>> To: Heiles, Juergen (NSN - DE/Munich)
>>>>>> Cc: ext Ben Niven-Jenkins; George Newsome;
>>>>>> [email-masked]; [email-masked]
>>>>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
>>>>>> transport path requirements)
>>>>>>
>>>>>> Juergen,
>>>>>>
>>>>>> see in line please.
>>>>>>
>>>>>> Heiles, Juergen (NSN - DE/Munich) wrote:
>>>>>>> Hi Loa,
>>>>>>>
>>>>>>> see my response below based on the behavior we have for
>>>>>> example in SDH
>>>>>>> networks.
>>>>>> part of this is discussion (at lest on my part) is that we need to
>>>>>> recognize that in certain respects SDH and packet networks are
>>>>>> different, and how also understand how this effects what we are
>>>>>> discussing
>>>>> I agree and already indicated some difference in my 
>> initial email on
>>>> the
>>>>> topic. In the context of the Ethernet OAM work and even 
>> before in the
>>>>> ATM days discussions on that issue took place, but also packet
>>>>> technologies are different and have their history. Just 
>> saying we have
>>>>> to do it because we always did it this way is not the way to go. We
>>>> have
>>>>> to have good reasons for a requirement.
>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Juergen
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: ext Loa Andersson [mailto:[email-masked]]
>>>>>>>> Sent: Tuesday, May 26, 2009 4:51 PM
>>>>>>>> To: Heiles, Juergen (NSN - DE/Munich)
>>>>>>>> Cc: ext Ben Niven-Jenkins; George Newsome;
>>>>>>>> [email-masked]; [email-masked]
>>>>>>>> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
>>>>>>>> transport path requirements)
>>>>>>>>
>>>>>>>> All,
>>>>>>>>
>>>>>>>> I have what might be a naive question.
>>>>>>>>
>>>>>>>> Consider a network configured this way, between two LSRs with
>>>>>>>> multiple hops between them we run two 40G LSPs, inside each
>>>>>> such LSPs
>>>>>>>> we have 400 100Mbit/s LSPs
>>>>>>>>
>>>>>>>> At each end we have of the tunnels we have a MEP for each
>>>>>> tunnel, and
>>>>>>>> MIPs for the 100 Mbit/s LSPs.
>>>>>>>>
>>>>>>>> Assume that we have failure somewhere else than at the
>>>>>> endpoints of the
>>>>>>>> tunnel.
>>>>>>> Actually it is not relevant where the failure occurs.
>>>>>> maybe not, I just wanted to look at a situation where the failure
>>>>>> were detected through the (lack of) OAM flow.
>>>>> The failure could be anywhere along the serve layer 
>> connection between
>>>>> the increase and egress server MEPs. We may have also failures with
>>>> OAM
>>>>> and data flows, for example a miss-connection to the wrong LSP. In
>>>> this
>>>>> case the packets should no longer be forwarded to the client layer.
>>>>> The behavior should be independent of the specific failure 
>> and type of
>>>>> server layer.
>>>>>
>>>>>>>> At both ends of the tunnel the tunnel MEP will detect the
>>>>>> failure, if
>>>>>>>> both directions are effected, as the OAM flow stops. 
>> The same will
>>>>>>>> happen end points of the tunneled LSPs.
>>>>>>>>
>>>>>>>> If only one direction is effected the end point (tunnel or
>>>>>>>> tunneled LSP)
>>>>>>>> will stop the OAM flow, and the other end (tunnel and 
>> tunneled LSP)
>>>>>>>> will (also) detect the failure.
>>>>>>>>
>>>>>>> I am not sure if it is required to shut down both direction
>>>>>> in case of a
>>>>>>> unidirectional failure. But it is not relevant.
>>>>>> may be not - but we have had a lot of ITU-T people 
>> telling us that if
>>>>>> you want to re-route a bidirectional LSP you need re-route both
>>>>>> directions, so that was the scenario I was looking at
>>>>> yes, but that does not mean that you stop the OAM flow. You should
>>>> still
>>>>> send OAM packets from the increase MEP along the LSP in order to
>>>> detect
>>>>> the actual state of it and see if it has recovered from the failure
>>>>> condition.
>>>>>
>>>>>>>> Now what will happen at the tunnel end-points?
>>>>>>>>
>>>>>>>> I assume that the tunnel end-point MEPs will tell the
>>>>>>>> corresponding MIPs
>>>>>>>> (one for each tunneled LSP) about the failure. It will also
>>>>>>>> tell the NMS
>>>>>>>> about the failure.
>>>>>>> The MEP will tell the NMS if it is a primary failure 
>> condition. For
>>>>>>> secondardy failure conditions see below.
>>>>>> how do we define "primary failure condition" in the 
>> packet network?
>>>>>> Is that a failure detected by the lack of OAM flow?
>>>>>>
>>>>> Primary failure is a failure where we assume that the cause of the
>>>>> failure is at that layer network, for example when we detect a
>>>>> miss-connection.
>>>>> A secondary failure is a failure where we assume that the 
>> cause is at
>>>> a
>>>>> server layer.
>>>>>
>>>>>>>> What will the MIPs at the tunnel end-point do?
>>>>>>> They should notify the downstream MEPs at the LSP end-points that
>>>> the
>>>>>>> LSP is interrupted due to a failure condition at a server layer.
>>>>>> Is this breaking the definition of a MIP, "a MIP is 
>> passive and won't
>>>>>> volunteer information unless told to do so" (my words, but
>>>>>> this is how I
>>>>>> understand how a MIP work).
>>>>> Using the term MIP in this context might be a too loose 
>> language. The
>>>>> function responsible for the insertion of the server layer failure
>>>>> indication notification is the adaptation function. The 
>> MIP is a point
>>>>> and located at the output of the adaptation sink or input of the
>>>>> adaptation source. So how we can see the functionality.
>>>>> The server layer is terminated at the trail termination sink and
>>>>> forwards the data to the adaptation sink which extracts the client
>>>>> signals. In case of a server layer failure the trail 
>> termination sink
>>>> no
>>>>> longer provides data to the adaptation but instead it 
>> indicates to the
>>>>> adaptation "Sorry no data packets available due to a failure
>>>> condition"
>>>>> (in the equipment functional model we use a Signal Fail 
>> signal going
>>>>> from the termination to the adaptation). The adaptation 
>> generates the
>>>>> "in-band" notification which basically says the same (no 
>> data packets
>>>>> available due to a server layer failure).
>>>>> A adaptation function does the mapping between client and 
>> server layer
>>>>> which can include recoding, stuffing and other things. In 
>> this case it
>>>>> is a recoding of the message "Sorry no data packets 
>> available due to a
>>>>> failure condition" in a form that is understood by the 
>> client layer.
>>>>> The actual MIP follows after the adaptation and a non-intrusive
>>>> monitor
>>>>> at this MIP would already detect the server layer failure
>>>> notification.
>>>>>> point here is that the MEP at the end-point will know about
>>>>>> the failure,
>>>>>> but not that it is a server layer failure, to understand 
>> that the MEP
>>>>>> will have to ask its upstream MIPs one by one until any 
>> of those are
>>>>>> able to tell whether it is a failure of the server layer (or the
>>>> client
>>>>>> layer itself)
>>>>>>
>>>>> The MEP shall not ask its upstream MIPs one by one which could get
>>>>> complex and take some time. The adaptation automatically 
>> inserts the
>>>>> notification.
>>>>>
>>>>>>>> What will the MEPs at the LSP end-points do? It is quite
>>>>>> obvious that
>>>>>>>> they will tell the NMS and their own client MIPs.
>>>>>>> They MEPs may tell the NMS about the interruption due to 
>> a failure
>>>> at
>>>>>>> the server layer. It is a secondary failure condition for
>>>>>> which the fault
>>>>>>> management reporting can be disabled.
>>>>>> See above.
>>>>>>
>>>>>> /Loa
>>>>>>>> Anything more?
>>>>>>>>
>>>>>>>>
>>>>>>>> /Loa
>>>>>>>>
>>>>>>>>
>>>>>>>> Heiles, Juergen (NSN - DE/Munich) wrote:
>>>>>>>>> Hi colleagues,
>>>>>>>>>
>>>>>>>>> I have been quiet for a long time, but now I think I have
>>>>>> to add my 2
>>>>>>>>> cents to this discussion.
>>>>>>>>>
>>>>>>>>> Different purposes of the AIS signal are mixed in the 
>> discussion.
>>>>>>>>> 1. In a TDM circuit switched network the resources for 
>> a certain
>>>>>>>>> connection (the time slots) are fixed assigned and have to
>>>>>> be filled
>>>>>>>>> even if the connection is interrupted due to an upstream
>>>>>> server layer
>>>>>>>>> failure. This replacement signal has to fulfill certain
>>>>>> criteria like
>>>>>>>>> for timing in order to prevent strange behavior and failure
>>>>>>>> conditions
>>>>>>>>> downstream like buffer overflow/underflow. One may
>>>>>> generate a random
>>>>>>>>> pattern or just send what is in the buffer. Such patterns
>>>>>> however may
>>>>>>>>> result in some strange defect detections downstream (at
>>>>>> non-intrusive
>>>>>>>>> monitors or path termination) which could have a 
>> negative impact
>>>> on
>>>>>>>>> protection switching. Therefore it makes sense to 
>> generate a well
>>>>>>>>> defined replacement signal.
>>>>>>>>> -> AIS purpose: a well behaving signal to prevent strange
>>>>>>>> and unwanted
>>>>>>>>> behaviors downstream of the failure with the layer network
>>>>>>>>>
>>>>>>>>> 2. One transport network paradigm is to have layer networks
>>>>>>>> decoupled so
>>>>>>>>> that each layer network can be operated on its own. When we
>>>>>>>> move to the
>>>>>>>>> physical layers or close to them this is however no longer 100%
>>>>>>>>> fulfilled. The SDH Regenerator section depends on the
>>>>>> clock from the
>>>>>>>>> Multiplex section (the same applies for OTU and ODU). If a
>>>>>> MS fails a
>>>>>>>>> replacement at least of the clock is required in order to
>>>>>>>> have a correct
>>>>>>>>> behavior at the downstream RS and other server layers. The
>>>>>>>> Optical and
>>>>>>>>> electrical layer require a certain pattern from their
>>>>>> digital client
>>>>>>>>> layers like RS or OTU in order to work correctly
>>>>>>>>> -> AIS purpose: ensure correct operation of downstream
>>>>>>>> server layers in
>>>>>>>>> cases where server and client layers are not 100% decoupled
>>>>>>>> (this is the
>>>>>>>>> example from George).
>>>>>>>>>
>>>>>>>>> 3. A failure of a server layer connection may effect a large
>>>>>>>> number of
>>>>>>>>> client layer connections that are transported via this 
>> connection.
>>>>>>>>> These client layer connections are terminated and monitored
>>>>>>>> at network
>>>>>>>>> elements that are far way from the actual failure location.
>>>>>>>> They might
>>>>>>>>> be even in a different management or operator domain.
>>>>>>>> Without AIS all of
>>>>>>>>> them would raise a primary failure alarm (loss of
>>>>>>>> connectivity). While a
>>>>>>>>> network element can differentiate between local and remote
>>>> failures
>>>>>>>>> based on local information, it cannot differentiate between
>>>>>>>> a failure at
>>>>>>>>> the monitored layer network or some server layer networks
>>>>>>>> upstream. With
>>>>>>>>> AIS it is possible.
>>>>>>>>> -> AIS purpose: alarm correlation to prevent alarm storms and
>>>>>>>>> differentiate between failures at the layer network and at
>>>>>>>> server layer
>>>>>>>>> networks.
>>>>>>>>>
>>>>>>>>> As a side effect, AIS detection is often much faster as loss of
>>>>>>>>> connectivity detection (e.g. SDH VC-4 TTI mismatch vs.
>>>>>>>> AU-AIS detection)
>>>>>>>>> and can trigger protection switching therefore faster. So
>>>>>>>> this might not
>>>>>>>>> be the case for MPLS-TP depending on the specific methods
>>>>>>>> that will be
>>>>>>>>> used.
>>>>>>>>>
>>>>>>>>> For MPLS-TP item 1 doesn't apply as it is a packet layer
>>>>>>>> network which
>>>>>>>>> doesn't require that packets are constantly sent for a certain
>>>>>>>>> connection.
>>>>>>>>> Item 2 does also not apply as the MPLS-TP layer network is
>>>>>> decoupled
>>>>>>>>> from other layer networks concerning its operation (I assume
>>>> so;-).
>>>>>>>>> This leaves us with item 3 which applies to any kind 
>> of transport
>>>>>>>>> network technology. So it is not a must have I see it as
>>>>>> very useful.
>>>>>>>>> Some operators might not be interested in it at all or do alarm
>>>>>>>>> correlation in the network management. Still they can do
>>>>>>>> that. They have
>>>>>>>>> to enable AIS alarm reporting and treat AIS alarms in the
>>>>>> same way as
>>>>>>>>> loss of connectivity alarms.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Juergen
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked]
>>>>>>>>>> [mailto:[email-masked]] On Behalf Of ext Ben
>>>>>> Niven-Jenkins
>>>>>>>>>> Sent: Friday, May 08, 2009 8:54 PM
>>>>>>>>>> To: George Newsome; [email-masked]
>>>>>>>>>> Cc: [email-masked]
>>>>>>>>>> Subject: Re: [mpls-tp] AIS/FDI (was
>>>>>>>>>> Associatedbidirectionaltransportpathrequirements)
>>>>>>>>>>
>>>>>>>>>> George,
>>>>>>>>>>
>>>>>>>>>> On 08/05/2009 18:05, "George Newsome" 
>> <[email-masked]> wrote:
>>>>>>>>>>> Huub van Helvoort wrote:
>>>>>>>>>>>> In MPLS-TP the CC provides the conductivity.
>>>>>>>>>>>> If a server layer fails, there are no packets
>>>>>> transited, including
>>>>>>>>>>>> the CC, so isn't there a need to show conductivity?
>>>>>>>>>>>>
>>>>>>>>>>> The servers that mpls-tp is to run on already provide
>>>>>>>>>> monitoring, and it
>>>>>>>>>>> is that OAM which shows the server conductivity. mpls-tp
>>>>>>>> will not run
>>>>>>>>>>> natively over a fiber, so does not need to carry its own
>>>>>>>> baggage for
>>>>>>>>>>> server conductivity checking.
>>>>>>>>>> This is a key point IMO. A piece of MPLS-TP equipment can
>>>>>>>>>> determine whether
>>>>>>>>>> a failure is local/remote by correlating information
>>>>>>>> acquired from the
>>>>>>>>>> various layer networks which terminate on it. It doesn't need
>>>>>>>>>> to have all
>>>>>>>>>> the information it requires be present in the MPLS-TP
>>>>>> layer network.
>>>>>>>>>> Ben
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> mpls-tp mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> mpls-tp mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>>>>> -- 
>>>>>>>>
>>>>>>>>
>>>>>>>> Loa Andersson
>>>>>>>>
>>>>>>>> Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
>>>>>>>> Ericsson ///                                 +46 767 72 92 13
>>>>>>>>
>>>>>>>>
>>>>>>>>                                       email:
>>>>>>>> [email-masked]
>>>>>>>>                                               [email-masked]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> -- 
>>>>>>
>>>>>>
>>>>>> Loa Andersson
>>>>>>
>>>>>> Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
>>>>>> Ericsson ///                                 +46 767 72 92 13
>>>>>>
>>>>>>
>>>>>>                                       email:
>>>>>> [email-masked]
>>>>>>                                               [email-masked]
>>>>>>
>>>>>>
>>>>>>
>>>> -- 
>>>>
>>>>
>>>> Loa Andersson
>>>>
>>>> Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
>>>> Ericsson ///                                 +46 767 72 92 13
>>>>
>>>>
>>>>                                       email:
>>>> [email-masked]
>>>>                                               [email-masked]
>>>>
>>>>
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>> _______________________________________________
>>>> mpls-tp mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>>>
>>>
>>> _______________________________________________
>>> mpls-tp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 

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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 01 Jun 2009 14:10:45 +0200

Nurit,

sorry but you lost me completely. I can figure out two ways of
interpreting this>

1. from now on we need to replace client layer MIPs that are
co-located with server layer MEPs, with client layer MEPs

2. from now on MIPs will need additional functionality that allows
them to behave as if they were MEPs in certain situations.

I don't like either interpretation, since the first one breaks
the maintenance entity concept, and the second take the MIP from being
something light and uncomplicated to something much more complex

/Loa

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> Hi,
> In Y.1731, we have a message that is initiated by the server MEP to the
> clients MEPs and is adapted by the clients located at the same NE as the
> server that initiates the message. In a way this involves inter-layer
> communication (or whatever). 
> notified (locally) by the server layer of the fault and if

-- 

Loa Andersson

                                       email:  [email-masked]
                                               [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 1 Jun 2009 14:18:53 +0200

Loa,

I did not refer to any of the two options below. 

I do NOT want a MIP to initiate OAM messages like CC, CV, diagnostics,
delay measurements, etc. The MIP should only respond to some of these
messages.

The intention was to allow a MIP to initiate only alarm notifications
(exactly as an SNMP agent initiates a trap but only respond to get and
set messages that are initiated by the management entity). 

I thought this is much cleaner and architecturally correct then sending
a message from a server layer MEP to a remote client layer MEP (which
involves communication between two MEPS residing in different layers and
do NOT reside at the same node). The adaptation function is just a means
to allow this inter layer communication. ]

I hope this clarifies the intention. 

Best regards,

Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Monday, June 01, 2009 3:11 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Heiles, Juergen (NSN - DE/Munich); ext Ben Niven-Jenkins; Adrian
Farrel; [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
pathrequirements)

Nurit,

interpreting this>

 

/Loa

-- 

Loa Andersson

 

                                       email:

                                               [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 1 Jun 2009 13:54:54 +0100

Hi,

> I do NOT want a MIP to initiate OAM messages like CC, CV,
> diagnostics, delay measurements, etc. The MIP should only
> respond to some of these messages.
>

I *really* don't think the comparison with SNMP holds any examination.
Since you only gave it as an example, can we drop it?

> to allow this inter layer communication.

Well, I certainly agree that allowing a server MEP to inject anything into 
the client layer (through an adaptation function!) is architecturally pretty 
poor. I think it also breaks the requirement for layer independence.

That definitely leaves only two options.

1. We redefine MIP to allow it to generate "alarm" notification OAM when it 
learns of a fault from the server layer.
I think this is your proposal, and I believe it *is* a change in the 
definition of MIP.
This change may be OK, but we would need to ensure that our definition 
remains in step with that used by the ITU-T and MEF.
I would note that it is an odd limitation to say that the MIP can only 
generate such alarm OAM for server layer faults, and indeed that still 
breaks the layer independence.
Instead, I suggest that what you want is that the MIP is allowed to generate 
alarm OAM for client layer faults. (When a server fault is reported inside 
the box from server MEP to client MIP, there is a mapping of server fault to 
client fault. This should not be a suprise - the client does not know about 
the server network and does not understand server layer fualts.)

2. We stick with the current design and accept that there is no difference 
between a client layer fault caused by a client layer failure (e.g. a matrix 
failure) and a client layer fault caused by a server layer failure (e.g. a 
fiber cut). Neither of these is directly reported by the MIP, but they are 
detected by the client layer OAM and may then be isolated also by client 
layer OAM. Correlation between client and server layers is provided in the 
MNS, OSS, etc.

Cheers,
Adrian

PS. We discovered in Sophia Antipolis that the precise meaning of fault, 
error, and failure were not clearly understood! These look like words for 
the Rosetta draft.
I hope this clarifies the intention.

Best regards,

Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Monday, June 01, 2009 3:11 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Heiles, Juergen (NSN - DE/Munich); ext Ben Niven-Jenkins; Adrian
Farrel; [email-masked]

Nurit,

interpreting this>

/Loa

-- 

Loa Andersson

                                       email:

                                               [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 1 Jun 2009 15:06:32 +0200

Hi Adrian,
I think you interpreted my proposal appropriately. Thanks.
Please see inline. <NS>
Best regards,
Nurit

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]] 
Sent: Monday, June 01, 2009 3:55 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson
Cc: Heiles, Juergen (NSN - DE/Munich); ext Ben Niven-Jenkins;
[email-masked]

Hi,

<NS> It is not a specification and we can drop the example. The
intention was to compare with a model of another client/server
relationship (like MIP and MEP). By the way we have the same model with
the control plane. 

> to allow this inter layer communication.

Well, I certainly agree that allowing a server MEP to inject anything
into 
the client layer (through an adaptation function!) is architecturally
pretty 
poor. I think it also breaks the requirement for layer independence.

<NS> Right. 

1. We redefine MIP to allow it to generate "alarm" notification OAM when
it 
learns of a fault from the server layer.
I think this is your proposal, and I believe it *is* a change in the 
definition of MIP.

<NS> I would say it is an extension and not a change. 

<NS> As I believe it is an extension (super set) and not a modification,
I think we have no issue here. 

<NS> The intention is to allow a MIP to notify of any fault it detects
(loss of light, cross-connect error, etc.) As we defined in previous
exchanges, when a server layers notifies its (co-located) clients of an
error, the error is considered a client error. 

Instead, I suggest that what you want is that the MIP is allowed to
generate 
alarm OAM for client layer faults. 

<NS> Indeed this was the intention. Thanks for making it clear. 

(When a server fault is reported inside 
the box from server MEP to client MIP, there is a mapping of server
fault to 
client fault. This should not be a suprise - the client does not know
about 
the server network and does not understand server layer fualts.)

2. We stick with the current design and accept that there is no
difference 
between a client layer fault caused by a client layer failure (e.g. a
matrix 
failure) and a client layer fault caused by a server layer failure (e.g.
a 
fiber cut). Neither of these is directly reported by the MIP, but they
are 
detected by the client layer OAM and may then be isolated also by client

layer OAM. Correlation between client and server layers is provided in
the 
MNS, OSS, etc.

<NS> I believe that option 1 has its benefits and can result in a more
efficient behavior. 

Cheers,
Adrian

error, and failure were not clearly understood! These look like words
for 
the Rosetta draft.
I hope this clarifies the intention.

Best regards,

Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Monday, June 01, 2009 3:11 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Heiles, Juergen (NSN - DE/Munich); ext Ben Niven-Jenkins; Adrian
Farrel; [email-masked]

Nurit,

interpreting this>

/Loa

-- 

Loa Andersson

                                       email:

                                               [email-masked]

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 1 Jun 2009 06:44:13 -0700

2. seems reasonable 

> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Monday, June 01, 2009 5:55 AM
> transportpathrequirements)
> 
> Hi,
> 
> diagnostics, 
> > I thought this is much cleaner and architecturally correct then 
> > sending a message from a server layer MEP to a remote 
> client layer MEP 
> > (which involves communication between two MEPS residing in 
> different 
> > layers and do NOT reside at the same node). The adaptation 
> function is 
> > just a means to allow this inter layer communication.
> 
> Well, I certainly agree that allowing a server MEP to inject 
> anything into the client layer (through an adaptation 
> function!) is architecturally pretty poor. I think it also 
> breaks the requirement for layer independence.
> 
> 1. We redefine MIP to allow it to generate "alarm" 
> notification OAM when it learns of a fault from the server layer.
> I think this is your proposal, and I believe it *is* a change 
> in the definition of MIP.
> This change may be OK, but we would need to ensure that our 
> definition remains in step with that used by the ITU-T and MEF.
> I would note that it is an odd limitation to say that the MIP 
> can only generate such alarm OAM for server layer faults, and 
> indeed that still breaks the layer independence.
> Instead, I suggest that what you want is that the MIP is 
> allowed to generate alarm OAM for client layer faults. (When 
> a server fault is reported inside the box from server MEP to 
> client MIP, there is a mapping of server fault to client 
> fault. This should not be a suprise - the client does not 
> know about the server network and does not understand server 
> layer fualts.)
> 
> 2. We stick with the current design and accept that there is 
> no difference between a client layer fault caused by a client 
> layer failure (e.g. a matrix
> failure) and a client layer fault caused by a server layer 
> failure (e.g. a fiber cut). Neither of these is directly 
> reported by the MIP, but they are detected by the client 
> layer OAM and may then be isolated also by client layer OAM. 
> Correlation between client and server layers is provided in 
> the MNS, OSS, etc.
> 
> Cheers,
> Adrian
> 
> PS. We discovered in Sophia Antipolis that the precise 
> meaning of fault, error, and failure were not clearly 
> understood! These look like words for the Rosetta draft.
> Adrian Farrel; [email-masked]
> [mailto:[email-masked]] On
>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 1 Jun 2009 15:55:16 +0200

Hi,
Option 2 will not allow us to support efficiently and rapidly the need
to suppress alarms that are generated as a result of the failure
condition in the server layer.
Mechanisms for fault localization will not be able to differentiate
between alarms that result from a failure condition in the server layer
and those that are created for example by a cross-connect error
somewhere along the path. 
It is only the NMS/OSS that can understand that the enormous number of
alarms it receives from the ingress nodes (for LSPs, PWs) result from a
server layer fault in the network and access all the related ingress
nodes to "shut down" the consequential alarms.
Option 1, provide a clean and an efficient tool to allow it. By the way,
option 1 can be beneficial for other applications (faster fault
detection and recovery operations). 
Best regards,
Nurit 

P.S. the control plane provides a similar functionality, but the
fundamental requirement in MPLS-TP is that the presence of a
control-plane is not mandatory and the data plane should provide all
capabilities regardless the way it is provisioned and managed. 

-----Original Message-----
From: ext Drake, John E [mailto:[email-masked]] 
Sent: Monday, June 01, 2009 4:44 PM
To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa
Andersson
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional
transportpathrequirements)

2. seems reasonable

---

From: <[email-masked]>
Date: Mon, 1 Jun 2009 18:05:29 +0100

A small but important point:

> Nurit wrote to Adrian 01 June 2009 14:07
<snipped to specific point>
 
> relationship (like MIP and MEP). 

Nested TCM OAM sublayering gives the impression of creating hierarchy.
However, it an artificial hierarchy created for the sole purpose of TCM
itself.  It is most definitely not a client/server layer network
relationship.

Aside=> As I have noted previously, any network that is not
top-of-stack...this includes MPLS.....has no technical justification for
E-NNIs.  The reason I make this point is to be clear that nested TCM
cannot be justified by any appeal to a horizontally partitioned
MPLS/MPLS-TP network between different parties.  This is not meant to
say folks can't do this, but just that it is technically not justified
and must not be a mandatory standards requirement on network operators.

regards, Neil

---

From: <[email-masked]>
Date: Mon, 1 Jun 2009 18:05:19 +0100

Nurit wrote 01 June 2009 14:55
> condition in the server layer.

NH=> And what if your operator customers tell you they do not want AIS
in MPLS-TP?

> somewhere along the path.

NH=> How come every packet network technology to date with the sole
exception of ATM (so that is IPv4, IPv6, FR, X.25, MPLS as-is, Ethernet,
etc) has worked fine without AIS? 

> nodes to "shut down" the consequential alarms.

NH=> Well, the correct way to mitigate with this is to reduce how many
layer networks there are between the top-of-stack networks that support
external message/file/stream applications and the bottom-of-stack
section layer network that modulates an EM wave on some
radio/metallic/optical media. 

We can also note that any non top-of-stack network does not need
horizontal E-NNI partitions between different parties....folks can go
and do this unnecessary work if they want but it must NOT be mandated on
operators who do not want it as it can be proved very simply that it is
not a technical requirement.  Given this, then an operator can have full
visibility of:
-	the end-end CV in the client layer N trail
-	the end-end trail CV in each server layer N-1 trail (that
provides each client layer N link connection, ie creates the client
layer topology).

In other words, AIS adds no information in determining whether a failure
is in layer N or layer N-1.

In the co-cs mode we must generate something to fill the 'dead' client
TSs....we have no choice.  This arises because the co-cs mode is based
on regular time-slices which have (i) a fixed start epoch (ie the label)
and (ii) duration (ie this is the assignment of real resource in some
number of bits and must be filed with something).

This is not a condition on the co-ps mode as the co-ps mode is based
irregular time-slices.  However, if we want to have AIS in the co-ps
mode then we must:
-	create the AIS traffic units
-	correctly label them for each client (on the assumption of some
permanence of client/server binding) 

I feel sure there must be scaling issues here wrt how many client AIS
MPLS-TP traffic units can be generated/unit-time when a very high bit
rate server section fails....perhaps some of the vendors would like to
comment on this, eg experience with ATM as the only packet mode
technology to have defined AIS previously.

Speaking as an operator, a real key requirement we have is that the
network must be intrinsically very reliable with rare faults.  This is
far more important to us than having fancy OAM.

This is why you will hear me keep saying that what we really need is the
most simple/sparse OAM possible in each mode (and it is not identically
the same in each mode)......we cannot afford to have to configure
shed-loads of nested MEPs/MIPs as per the TCM ideas.

The best network would be one with no defects and required no OAM....or
at least the minimum possible.  IMO the primary OAM flows should only be
on an end-end trail basis.  Only if these show a problem do we need to
look deeper inside the network.  And here all we really need is the
ability tap-off the end-end CV/PM flows at intermediate nodes.  So we
have no need to implement lots of a priori configured TCM levels 'just
in case', especially since this action in itself will introduce the
potential for worsening the intrinsic network reliability.

So what can go wrong with AIS generation?  Well, it might fail to be
generated when expected (per se or due to scaling limits), it might get
injected when it shouldn't be, it might fail to be be turned-off when it
should be, it might get the wrong label values inserted (so AIS turns up
at the wrong place), we might get CV and AIS packets appearing together
(perhaps due to the previous AIS fault).

When we in BT studied this AIS issue for packet networks a few years ago
we concluded that we would be better off without it.

regards, Neil

<snipped to end>

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 1 Jun 2009 20:40:49 +0200

Hi Neil,
When I talked about a client/server relationship between MIPs and MEPs I
did NOT refer to TCM or to any relationship between layers. I referred
to MIPs and MEPS at the same layer network. 
In management we have a client/server relationship between the
management and the agent entities, and I thought we have a similar
relationship between MIPs and MEPs at the same layers. 
I think we can say that the MIPs are the clients of the MEPs, they
respond to some of the MEPs requests. 
Best regards,
Nurit

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 01, 2009 8:05 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
[email-masked]
Cc: [email-masked]

 

regards, Neil

---

From: <[email-masked]>
Date: Mon, 1 Jun 2009 20:13:32 +0100

Thanks Nurit,

I am perhaps a little sensitive to terminology...and how it can be
(mis/ab)used.  TCM creates sublayers...this is not a true client/server
*traffic DP* relationship.  So, I guess the real issue is do network
operators *really* want TCM sublayers...and the AIS that is required to
make these work as an artificial/imposed OAM hierarchy?.  We for sure do
not need AIS in a *traffic* sense IMO in packet networks (and in the
cl-ps mode this is so painfully obvious it hardly needs stating IMO).

TCM looks superficially attractive to the uninitiated, but when you
really understand the details and get to the crux of the OAM issues TCM
does not look that great IMO.  TCM is not really solving my real
problems....but it might create some new problems for me (if/when the
TCM/AIS goes awry).

I think we are starting with the wrong OAM end-game model in mind.  The
best OAM is no OAM, ie a network is so reliable it creates no
defects.....practically we realise this nirvana cannot be achieved, but
the real challenge is to try and get as close to this as possible...and
the totally wrong OAM philosophy is one of blanketing the network(s) in
shed-loads of a priori configured OAM sublayers (per layer).  One
obvious aim is to reduce the amount of layer networks between a real
external application and the section layer EM wave modulation....this is
a great goal.

The other important point here is to really get your head round why the
3 modes are different...and not just in OAM requirements.

What we MUST avoid is the generation of unnecessary work/complexity/cost
just 'because we can do something'.....I see TCM, AIS in packet
networks, E-NNIs in non top-of-stack layer networks (or much worse, peer
interworking between different non top-of-stack modes/technologies) all
very much in that vein.

regards, Neil

> From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
> [mailto:[email-masked]] 
> Sent: 01 June 2009 19:41
> To: Harrison,N,Neil,CXM R; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 1 Jun 2009 21:18:35 +0200

Hi Neil,

Please see inline. <NS> 

Best regards,

Nurit

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]] 
Sent: Monday, June 01, 2009 8:05 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

in MPLS-TP?

<NS> 

1.    In general, operators' requirements and input are very welcome and
much appreciated, whether it is my customer or not. Your input and
experience is very valuable and brings a lot of useful information on
how networks should be operated. And by the way, I really agree that a
"network must be intrinsically very reliable with rare faults".  Still I
believe we need OAM functionality to handle these rare cases. 

2.    I did not refer to AIS at all. AIS, from my point of view, is a
specific implementation that was defined in ITU-T. The requirement
mentioned above, may be implemented by different means than AIS. I
referred to a requirement for which I have seen interests from customers
(without discussing how to implement it). I will really appreciate if
other operators express their needs and requirements on the list as
well.  

3.    As was agreed, the joint work on MPLS-TP should address the
requirements of the ITU-T and additional requirements coming from SPs.
It seems that as the ITU-T expressed their need for such a function, we
will need to define a protocol function to support it. My intention is
that such a function will be supported using a clean architecture and
keep the independence between layers. Note: in the IETF we define
requirements for the protocol only. The protocol must/should/etc support
function x. Nothing mandates the implementers or the operators. MPLS and
MPLS-TP is a toolkit. 

4.    Allowing the MIPs to initiate alarms/notification to the MEPs (at
the same layer network) can be beneficial for other applications than
AIS (e.g. faster fault detection and recovery, etc.)  

<NS>

> between alarms that result from a failure condition in the 

> alarms it receives from the ingress nodes (for LSPs, PWs) 

> result from a

visibility of:

layer topology).

mode then we must:

regards, Neil

<snipped to end>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 01 Jun 2009 21:48:27 +0200

Adrian,

The MIP is an optional function and is as such not the place to insert any
necessary alarm suppressing OAM.

The adaptation function is defined to include client specific processes and
server specific processes. It is the only function that has awareness of
both layers, and as such is THE right function to insert client specific OAM
that is generated under control of server layer defects.

We can and should as such use the common, technology independent OAM
architecture for alarm suppressing maintenance signals for MPLS-TP as well,
and have MPLS-TP alarm suppression maintenance signal inserted by the
adaptation sink function.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: maandag 1 juni 2009 14:55
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa Andersson
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
transportpathrequirements)

Hi,

> sending a message from a server layer MEP to a remote client layer MEP 
> (which involves communication between two MEPS residing in different 
> layers and do NOT reside at the same node). The adaptation function is 

Cheers,
Adrian

Best regards,

Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Monday, June 01, 2009 3:11 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Heiles, Juergen (NSN - DE/Munich); ext Ben Niven-Jenkins; Adrian Farrel;
[email-masked]

Nurit,

interpreting this>

/Loa

-- 

Loa Andersson

                                       email:

                                               [email-masked]

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 1 Jun 2009 16:26:34 -0400

> interworking between different non top-of-stack modes/technologies)  

	I'd agree with the last statement; I cannot understand why we are going
down the road of AIS for MPLS-TP myself given all the other OAM  
available in the
base technology.  Lets be clear on what precise problem we are trying  
to solve here
before we duplicate SONET/SDH verbatim "just because".

	--Tom

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 2 Jun 2009 08:20:02 +0300

Maarten,
I agree that MIPSs absolutely must not insert any OAM packets save from responses to requests generated by MEPs. And I agree that the data plane adaptation function would be the right place to insert downstream AIS in the clients. In fact, this is exactly what happens in SONET/SDH at all layers.

The problem, however, is that in SONET/SDH the dataplane adaptation function is required regardless of OAM functionality: it is needed to extract the client data from the server (pointer processing). In order to do that correctly, it MUST be aware of all specific clients at the given server trail termination point (since it must know where to look for the pointers, must monitor - or not to monitor - for the multiframe alignment etc.)

In the MPLS dataplane (which presumably is inherited by MPLS-TP without any changes) the adaptation function is NULL. Extraction (pop of the top label) is done by the server termination point. Introducing such a function and providing it with specific knowledge just in order to support some questionable OAM functionality (I think that Neil, Ben and some others have provided sufficient input  - and then some - on this list to justify my using the qualifier "questionable") would be, IMHO and FWIW, one more case of the tail wagging the dog. And this equally applies to the attempts to impose a universal OAM architecture on different network models.

My 2c,

     Sasha

Sent: Monday, June 01, 2009 10:48 PM
To: 'Adrian Farrel'
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transportpathrequirements)

Adrian,

Regards,
Maarten

-----Original Message-----

Hi,

Cheers,
Adrian

Best regards,

Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Monday, June 01, 2009 3:11 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Heiles, Juergen (NSN - DE/Munich); ext Ben Niven-Jenkins; Adrian Farrel;
[email-masked]

Nurit,

interpreting this>

/Loa

--

Loa Andersson

                                       email:

                                               [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 02 Jun 2009 10:11:32 +0200

Sasha,
 
See inline...

  _____  

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: dinsdag 2 juni 2009 7:20
To: Maarten Vissers
Cc: [email-masked]; 'Adrian Farrel'
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional
transportpathrequirements)

Maarten,
I agree that MIPSs absolutely must not insert any OAM packets save from
responses to requests generated by MEPs. And I agree that the data plane
adaptation function would be the right place to insert downstream AIS in the
clients. In fact, this is exactly what happens in SONET/SDH at all layers. 

[mv] Thank you. 

The problem, however, is that in SONET/SDH the dataplane adaptation function
is required regardless of OAM functionality: it is needed to extract the
client data from the server (pointer processing). In order to do that
correctly, it MUST be aware of all specific clients at the given server
trail termination point (since it must know where to look for the pointers,
must monitor - or not to monitor - for the multiframe alignment etc.)

In the MPLS dataplane (which presumably is inherited by MPLS-TP without any
changes) the adaptation function is NULL. Extraction (pop of the top label)
is done by the server termination point.  

[mv] I have a different understanding of this. There is a client layer
connection function, which is connected to N client layer link ends and M
client layer access groups (client termination functions). Each client layer
link end holds the 20-bit label values which identify each individual client
layer signal within the link.

[mv] The N client layer link ends are supported by a server-to-client
adaptation function and a server layer termination function. 

- The server layer termination function provides server layer OAM
termination and is 

  **unaware of the individual client signals**; i.e. is unaware of the
individual client layer 20-bit label values. 

- The server-to-client adaptation functions contain both server layer
knowledge and client layer knowledge. 

  # The adaptation source function is the function that will insert the
20-bit label and 3-bit TC fields

     of the client's label stack entry header. Refer to Figure 1/G.8110
(http://www.itu.int/rec/T-REC-G.8110-200501-I/en).

  # The adaptation sink function is the function that will remove the 20-bit
label and 3-bit TC fields

     from the client's label stack entry header.

[mv] As you can see, the adaptation function is **not** a NULL function. The
adaptation source and sink functions hold the 20-bit label values that
identify each client signal.

[mv] The alarm suppression OAM (e.g. AIS) generation function makes use of
this client signal identification information present in the link
end/adaptation function. Client-AIS OAM frames are generated for all
registered client signals (i.e. for all client signals that have a 20-bit
label registered at the link end). 

Regards,

Maarten

 Introducing such a function and providing it with specific knowledge just
in order to support some questionable OAM functionality (I think that Neil,
Ben and some others have provided sufficient input  - and then some - on
this list to justify my using the qualifier "questionable") would be, IMHO
and FWIW, one more case of the tail wagging the dog. And this equally
applies to the attempts to impose a universal OAM architecture on different
network models.  

My 2c,

     Sasha

Adrian,

Regards,
Maarten

-----Original Message-----

Hi,

Cheers,
Adrian

Best regards,

Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]]
Sent: Monday, June 01, 2009 3:11 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Heiles, Juergen (NSN - DE/Munich); ext Ben Niven-Jenkins; Adrian Farrel;
[email-masked]

Nurit,

interpreting this>

/Loa

--

Loa Andersson

                                       email:

                                               [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 2 Jun 2009 10:00:37 +0100

Maarten,

What you say is very important, and (I believe) highlights the crucial 
issue.

If the server layer inserts OAM through an adaptation function into the 
client layer data stream, that adaptation function has to be aware of 
several features of the client layer.

Firstly, it needs to understand the mapping of server layer fault to client 
layer fault. This is because we must not report server layer faults in the 
client layer - operational layer independence is a requirement strictly 
specified and mandated by the ITU-T. It *is* technically possible to include 
this as an abstract function in the adaptation function since that function 
knows the client type. But it is not possible to perform the mapping in real 
terms since the server does not know the use of the server trail that the 
client is making.

For example, and in MPLS-TP terms, suppose that the server trail was 
currently unused. The adaptation function would insert a client packet as 
though it had arrived from the server trail. How would this packet be 
handled by the client layer? Presumably it would be delivered to the matrix 
and *hopefully* dropped.

And that leads to the second point...
What does the packet inserted into the client layer look like?
The server adaptation function pushes a label on the way down, and pops one 
on the way up.
But the adaptation function has no idea what label to apply in the client 
layer.
Which component is going to sort that out?

Adrian

PS
I remain unconvinced that the type of alarm suppression you want to achieve 
is either beneficial or desirable.

----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'Adrian Farrel'" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 01, 2009 8:48 PM
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional 

> Farrel;

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 2 Jun 2009 12:21:35 +0300

Maarten,
I've snipped everything beyond your explanation and added some inline comments (magenta italics) to those inline below.

Regards,
     Sasha

... snipped ...

[mv] I have a different understanding of this. There is a client layer connection function, which is connected to N client layer link ends and M client layer access groups (client termination functions). Each client layer link end holds the 20-bit label values which identify each individual client layer signal within the link.
[[Sasha]] Could you possibly clarify what a link means in this context? And can you map this view top the MPLSD architecture as described in RFC 3031 (with or without 5331 extensions as noted by John on this list)?

[mv] The N client layer link ends are supported by a server-to-client adaptation function and a server layer termination function.

- The server layer termination function provides server layer OAM termination and is
[[Sasha]] I would expect the server LSP termination function to do something in the dataplane beyond the OAM - and, in my description it does:  it pops tithe top label, checks whether the packet is still labeled, and, if it is, forwards it to the appropriate ILM look-up at the top remaining label.

Could you explain what the server LSP termination function does in your case beyond OAM?

  **unaware of the individual client signals**; i.e. is unaware of the individual client layer 20-bit label values.

- The server-to-client adaptation functions contain both server layer knowledge and client layer knowledge.
[[Sasha]] Again, can you map this function to MPLS architecture as defined in RFC 3031 and RFC 5331?

  # The adaptation source function is the function that will insert the 20-bit label and 3-bit TC fields

     of the client's label stack entry header. Refer to Figure 1/G.8110 (http://www.itu.int/rec/T-REC-G.8110-200501-I/en).
[[Sasha]] IMHO and FWIW the valid reference for MPLS architecture is RFC 3031 augmented by 5331. And it is this architecture that has been implemented in the silicon so far (as Francesco has mentioned on this list. If the ITU-T spec assumes a different architecture, it should be re-hashed.

  # The adaptation sink function is the function that will remove the 20-bit label and 3-bit TC fields

     from the client's label stack entry header.
[[Sasha]] IMHO and FWIW the real MPLS architecture does not suit your description. The labels are not popped and pushed by the adaptation function, they are swapped. You can model it in the ITU-T language, if you wish, but validity of such a model  would not be guaranteed.

 ...snipped to the end

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 2 Jun 2009 08:09:09 -0700

Sasha,

I think 'questionable' about covers it, although I am also partial to
'ill considered'.

Thanks,

John 

> Sent: Monday, June 01, 2009 10:20 PM
> To: Maarten Vissers
> Cc: [email-masked]
> I agree that MIPSs absolutely must not insert any OAM packets 
> save from responses to requests generated by MEPs. And I 
> agree that the data plane adaptation function would be the 
> right place to insert downstream AIS in the clients. In fact, 
> this is exactly what happens in SONET/SDH at all layers.
> 
> The problem, however, is that in SONET/SDH the dataplane 
> adaptation function is required regardless of OAM 
> functionality: it is needed to extract the client data from 
> the server (pointer processing). In order to do that 
> correctly, it MUST be aware of all specific clients at the 
> given server trail termination point (since it must know 
> where to look for the pointers, must monitor - or not to 
> monitor - for the multiframe alignment etc.)
> 
>  
> 
> In the MPLS dataplane (which presumably is inherited by 
> MPLS-TP without any changes) the adaptation function is NULL. 
> Extraction (pop of the top label) is done by the server 
> termination point. Introducing such a function and providing 
> it with specific knowledge just in order to support some 
> questionable OAM functionality (I think that Neil, Ben and 
> some others have provided sufficient input  - and then some - 
> on this list to justify my using the qualifier 
> "questionable") would be, IMHO and FWIW, one more case of the 
> tail wagging the dog. And this equally applies to the 
> attempts to impose a universal OAM architecture on different 
> network models.  
> 
>  
> 
> My 2c,
> 
>      Sasha
> 
>  
> 
>  
> 
> 
> 
> 
> 
> The MIP is an optional function and is as such not the place 
> to insert any necessary alarm suppressing OAM.
> 
> The adaptation function is defined to include client specific 
> processes and server specific processes. It is the only 
> function that has awareness of both layers, and as such is 
> THE right function to insert client specific OAM that is 
> generated under control of server layer defects.
> 
> We can and should as such use the common, technology 
> independent OAM architecture for alarm suppressing 
> maintenance signals for MPLS-TP as well, and have MPLS-TP 
> alarm suppression maintenance signal inserted by the 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel