Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectionaltransportpathrequirements)

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 20:55:43 +0200

Shahram,

In 1+1 AIS will generated by the adaptation function supporting the failed
working connection. As long as the selector reads from this working
connection, AIS will be forwarded to the far end endpoint. As soon as the
selector reads from the protection connection, AIS generated by the working
connection adaptation fucntion will drop dead at the input of the selector.

I don't know if FRR is a protection switching method or if it is a
restoration method. If it is a protection switching method, then a link
fault will result in generation of AIS on all active client connections of
the link. The protection selector will forward such AIS packet as long as it
reads from the failed link. Once it switches to the alternative link, the
AIS packets will drop dead at the input of the selector.

If FRR is a restoration method, then a fault in a link will result in
setting up an alternative path and in withdrawing the bindings with the
failed link. Initially the failed link endpoint will emit AIS for each
registered client connection; as soon as a registration is withdrawn (due to
restorations), generation of AIS for this client connection stops.

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: dinsdag 28 april 2009 18:24
To: 'Maarten Vissers'
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Maarten,

How about in 1+1? Or in FRR? will AIS be forwarded?

Shahram

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: April-28-09 12:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Shahram,

When you apply protection you will not change the binding between client and
server layers when you switch from e.g. working to protection. All
client/server bindings are still present. What you changed is the
connectivity in the connection function. You find this illustrated in e.g.
G.806.

When the working connection would fail, then AIS would be inserted e.g. at
the end of the server layer connection that carries the working connection.
AIS is inserted independent of the state of the next protection switch
selector process. If the selector is not moved to the protection connection,
then AIS inserted into the working connection is forwarded through the
protection switch selector to the far end of the protected connection. If
the selector is moved to read from the protection connection, then AIS is
still inserted intto the working connection, but the selector is not reading
from working, so AIS will drop dead at the input of the selector.

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: dinsdag 28 april 2009 17:57
To: 'Igor Bryskin'; 'Maarten Vissers'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Igor,

Your assumption is that there is a control plane that sets up the binding
between client and server layer and that such binding will be removed via
the control plane when a reroute happens. I think this assumption is not
always true. For example in a linear 1:1 or 1+1 protection, there is no
signalling to withdraw the binding at intermediate nodes. In 1:1 there is
APS, but that is end-to-end and is sent on the backup path not working path.

-Shahram

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: April-28-09 11:27 AM
To: [email-masked]; 'Maarten Vissers'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Shahram,

Let's assume that connection A-B-C-D-E is dynamically provisioned by a
control plane. As part of such provisioning a binding is created between
this connection and network C at the two adaptation points on either side of
the link provided by network C. When the connection is torn down, this
binding is removed as a part of the cleanup process. The re-routing of the
connection onto A-F-G-E is indistinguishable from the connection tear down
as far as link C is concerned.

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Hi Igor,

How does the server know the client is rerouted? Assume the following
networks: A-B-C-D-E (working) and A-F-G-E (protection). Assume each has its
own server layer such as MPLS, MPLS-TP, ATM, SONET, etc. Assume that network
C uses MPLS-TP as server layer. Network C will never know there was a
protection switching done for the client layer. 

-Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Igor Bryskin
Sent: April-28-09 11:05 AM
To: Maarten Vissers; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Neil.

I actually agree with Maarten on this. I don't quite understand why do you
keep talking about fixed client-server relationship. It is fixed as long as
the client layer connection configured this way (statically or dynamically).
As soon as the connection is re-routed, this relationship is broken (because
this is a part of the re-routing process) and hence the server trail
termination points will know that the server trail now serves one connection
less, whereas some other server trail(s) will learn that they serve from now
on one connection more. These new client-server relationships are fixed
until the next re-routing.

Cheers,
Igor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: Tuesday, April 28, 2009 8:48 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Neil,

> However, if the client can dynamically change its routing in response 
> to link failures in its topology (because some server layer network 
> has failed....which may or may not belong to the same operating party 
> as the
> client) then there is no fixed client/server relationship. 

I believe there is a fixed client/server relationship also in this case in
the network. This relationship is broken when the connection is rerouted.
Such reroute will remove the CP/FP and as such will stop the AIS generation.

There is no difference with what we do today in SDH and OTN. A client/server
relationship is fixed until the point in time that the connection is either
teardown or rerouted. When either of the two cases occur, the AIS generation
is stopped. Until such action is performed, AIS is generated during signal
fail condition period and inserted into the connection.

In MPLS-TP we have the requirement that MPLS-TP must be able to operate
without control plane. This implies that it will operate without
restoration, and that there will not be frequent rerouteing ongoing. Result
is that client/server relationships will last until the connection is
teardown.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 28 april 2009 10:07
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated
bidirectionaltransportpathrequirements)

Nurit,

I believe the reason we need this discussion is that there is an unstated
assumption here that the client/server relationship is fixed.
However, if the client can dynamically change its routing in response to
link failures in its topology (because some server layer network has
failed....which may or may not belong to the same operating party as the
client) then there is no fixed client/server relationship.

Refer to my post earlier today and consider what this means in the case of a
cl-ps IP client layer network or a some SVC-based co-ps/co-cs mode client
layer network.  The key point here is the *routing process* in the client is
independent of the server layer network....so there is not a fixed
client/server relationship.  Further, there is also no requirement for the
server to keep track of where its client traffic routings are at any
epoch.....indeed why should it in the general case where these are
independent layer networks?

So the only OAM requirement that is critical is that the OAM of the client
and server layer networks are independent.  It is thus not sensible to make
client layer alarm supression a 'requirement' here...in fact if this is in
the OAM requirements then it is technically wrong and should be removed IMO.

regards, Neil 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - 
> IL/Hod HaSharon)
> Sent: 28 April 2009 08:46
> To: ext BUSI ITALO; [email-masked]; Adrian Farrel
> Cc: [email-masked]
> Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
> transportpathrequirements)
> 
> If we agree that the requirement is included, so why do we keep with 
> the endless discussions on this requirement?
> 
> -----Original Message-----
> From: ext BUSI ITALO [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2009 10:44 AM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; 
> Adrian Farrel
> Cc: [email-masked]
> Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport
> pathrequirements)
> 
> I think that the requirements are defined in section 2.2.8 of
> draft-ietf-mpls-tp-oam-requirements-01
> 
> Italo
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN
> > - IL/Hod HaSharon)
> > Sent: Tuesday, April 28, 2009 6:56 AM
> > To: [email-masked]; Adrian Farrel
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
> > transport pathrequirements)
> > 
> > Huub,
> > I think that the requirement is to provide a mechanism to suppress 
> > alarms in the networks, to ensure that alarms that may be
> generated by
> > client layers as a result of a failure condition in the server layer 
> > may be suppressed.
> > Every thing else is a solution, etc. 
> > I propose to phrase the requirement appropriately and conclude the 
> > discussion on this in the context of the requirements (until we are 
> > getting to the solution phase).
> > This requirement is included in the OAM requirement draft. 
> > Best regards,
> > NUrit
> > 
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of ext Huub van Helvoort
> > Sent: Tuesday, April 28, 2009 12:27 AM
> > To: Adrian Farrel
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] AIS/FDI (was Associated
> bidirectional transport
> > path requirements)
> > 
> > Hi Adrian,
> > 
> > You wrote:
> > 
> > > Isn't the solution here the same as the one I proposed for "TCM"?
> > 
> > Indeed, and that we do not have to around in circles about TCM.
> > 
> > How about:
> > the requirement is that a server layer shall inform its clients that 
> > it has detected a service interuption, this to ensure that the 
> > clients can inhibit (unnecessary) alarms.
> > 
> > Cheers, Huub.
> > 
> > --
> > ================================================================
> >                    http://www.van-helvoort.eu/ 
> > ================================================================
> > Always remember that you are unique...just like everyone else...
> > _______________________________________________
> > 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

_______________________________________________
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

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 28 Apr 2009 21:30:27 +0200

Shahram,

Merging is I believe outside the scope of MPLS-TP...

If this type of merging is inside the scope of MPLS-TP then AIS will indeed
be forwarded. This then becomes similar to the n-port VLAN case. I.e. in a
VLAN one of the branches may be disconnected, whereas other branches are
still connected. The disconnected branch will insert ETH AIS to inform the
downstream endpoints that there is a server layer failure. Any loss of CC
detected at those endpoints will be suppressed by AIS. AIS has no impact on
loss of CC detectors itself or on loss of CC fault cause determination for
loss of CC detectors that still receive the expected CC frames.

With the merging in FRR you will notice the same behaviour. If the reroute
results in recovery of the connection, then the AIS packet will be received
by the endpoint. At the endpoint it will be discarded as there is nothing to
suppress.

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: dinsdag 28 april 2009 21:12
To: 'Maarten Vissers'
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated

Hi Maarten,

In FRR there is merging at the sink node and there is no selector. So AIS
will be forwarded.

-Shahram

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: April-28-09 2:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated

Shahram,

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: dinsdag 28 april 2009 18:24
To: 'Maarten Vissers'
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated

Maarten,

Shahram

-----Original Message-----
From: Maarten Vissers [mailto:[email-masked]]
Sent: April-28-09 12:09 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated

Shahram,

Regards,
Maarten

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: dinsdag 28 april 2009 17:57
To: 'Igor Bryskin'; 'Maarten Vissers'; [email-masked];

Igor,

-Shahram

-----Original Message-----
From: Igor Bryskin [mailto:[email-masked]]
Sent: April-28-09 11:27 AM
To: [email-masked]; 'Maarten Vissers'; [email-masked];

Shahram,

Igor

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, April 28, 2009 11:15 AM
To: Igor Bryskin; 'Maarten Vissers'; [email-masked];

Hi Igor,

-Shahram

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

Neil.

Cheers,
Igor 

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

Neil,

Regards,
Maarten

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

Nurit,

regards, Neil