Subject: RE: draft-ietf-pwe3-control-protocol-08.txt Generalized FECclarific ation

From: [email-masked]
Date: Wed, 29 Sep 2004 09:16:33 +0100

Nurit,

You are raising some fundamantal issues that have never been properly
addressed.  Please see below.

Nurit Sprecher wrote 28 September 2004 19:15
> 
> If N:1 should be used, it definitely should be generalized. 
> However, there are some issues in doing this as follows:
NH=> There is an up-front overriding requirement:  In any client/server
relationship (which is what all PWs are) the default behaviour should
always be client and server layer indepedence, of which a key corollary
is the need for client layer (data/control/management-plane)
transparency.

> 1. PW status notification a. When notifying a remote peer on a 
> service forwarding error, due for example to a port error, 
> how do you notify it?
NH=> If the OAM of the client and server layer are independent they
should look after themselves correctly.  Further, the defect
detection/handling must be intrinsically unidirectional and be done in
the data-plane in co-ps and co-cs technologies (and this is especially
important when folks consider mp2p constructs).  Now when a server layer
experiences a defect, this should be detected/handled at its trail
termination point (in the data-plane).....and one key 'handling'
requirement here is that it must send an FDI into its client's
data-plane (across the server->client adaptation function) to let them
know the defect is not in their layer networks (ie to effect alarm
supression in the clients).  The FDI is recursive into any further
client layers.  Now this implies that the server trail termination
function must retain knowledge of its clients so that, on failure, it
knows which ones to send the FDI to......this is the answer to your next
question below.  This behaviour is not something new.  It is an
operational requirement that has been known/understood for a long time
by operators and their major suppliers.  However, this behaviour does
not apply to the cl-ps mode, nor is it so obvious when dealing with a
single/flat layer network.......which is why historically I guess it is
not something some folks in IETF might readily see.  However, with MPLS
and GMPLS these things do need to be better understood.

> How can the remote peer distinguish and 
> identify which specific service is affected?
NH=> Please see above.

> 2. AC QoS a. In 
> TE environment, the service's QoS is of the AC. What is the 
> related QoS in case of a trunk?
NH=> The basic behaviour is that a client will inherit the network
performance impairments of its server and then add its own performance
impairments.....clearly this behaviour is recursive upwards from the
duct.  Or putting this another way, as one moves towards the duct one
loses sight of the individual network performance requirements of
specific applications in a higher client layer network, and this implies
that the transfer performance of the server layer must always be
'better' than any of its clients.  This is one reason why the lowest
layer networks used for bulk transport are invariably co-cs in nature,
ie SDH/Sonet, OTNs.  The co-cs mode does not do 'multiple QoS classes'
by definition....it only has 1 class, and its the best you can get. 

Currently there are no hard/fast rules for:
-	what are the allowed client/server relationships between the 3
network modes
-	how many such client/server transitions are allowed in some
global reference network 
-	what the end-end performance objectives are and how these should
be apportioned to partitions (eg operator domains) within that refernce
network

These issues start to get important when operators enter into
contractual relationships between themselves and their customers.
Further, there are also regulatory obligations some operators have to
meet that are relevant here.  If the basic layer network arch of the
mode considered is not right then there will be problems addressing the
above in any simple and cost-effective way.

However, given what I have seen happening and where things stand today,
I now have very little confidence that we will able to address the above
issue any time soon.

regards, Neil

> The QoS is the overall QoS 
> required for the trunk? This is an issue in TE service 
> provisioning, especially in multi-domains, but also in NMS 
> provisioning when attaching a PW to a specific TE Tunnel. A 
> CAC should be done on TE tunnel to verify it has sufficient 
> resources for the service emulated. 3. Etc.
> 
> I think that a new PW type should be defined, and a new 
> entity defining the emulated service (trunk?), etc.  
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Mustapha Aissaoui
> Sent: Tuesday, September 28, 2004 17:37
> To: Busschbach, Peter B (Peter)
> Cc: [email-masked]'; 'Luca Martini'
> Subject: Re: [PWE3] draft-ietf-pwe3-control-protocol-08.txt 
> Generalized FEC clarific ation
> 
> Peter,
> the text proposed by Amulya in his email suggested that he 
> was trying to generalize the N:1 encapsulation to carry not 
> just VPs coming on a given port, but a mix of VPs and VCs 
> coming from different ports.
> 
> He was also suggesting to use LDP status notifications to 
> add/remove an a VC or VP into the already established PW.
> 
> That was of course not the Virtual Trunk application you are 
> describing here and which is being specified in the MFA.
> 
> Regards,
> Mustapha.
> 
> "Busschbach, Peter B (Peter)" wrote:
> >
> > Luca wrote:
> >
> > > Yes , I am.  The question I have is the following:
> > > Why do we have to transmit status of individual VPs in the LDP 
> > > control protocol ?
> > > ATM does a pretty good job already ... If the PW goes down
> > > then we have
> > > to know the VPs in use , and generate the appropriate OAM F4
> > > cells ....
> > > But the PW status down message is already there....
> > >
> > > Luca
> > >
> >
> > Luca,
> >
> > Your comment is related to a discussion on ATM Virtual 
> Trunks and OAM.
> >
> > Let me explain the broader context. Manoj started this 
> thread with a 
> > question about mapping multiple VPs onto a PW. You 
> mentioned that only 
> > n=1 is currently supported in the atm-encap draft, upon 
> which I made 
> > the point that you could interpret the draft as supporting n>1 as 
> > well. I referred to the work that is going on in the MPLS 
> Frame Relay 
> > Alliance (MFA).
> >
> > The MFA is working on an Implementation Agreement on 
> MPL-ATM Control 
> > Plane Interworking. Among other things, it defines the concept of 
> > Virtual Trunks. A Virtual Trunk is a contiguous set of VPIs 
> with a one 
> > ATM signaling and one ATM routing channel that run through 
> the VP with 
> > the lowest VPI in the range. The ATM Switches at either end of the 
> > Virtual Trunk use the signaling channel to set up VPCs and VCCs 
> > through the trunk.
> >
> > Virtual Trunks are primarily used in the following scenario:
> >
> > ATM Switch 1   ---1--  PE1 ----2----  PE2 ---3--- ATM Switch 2
> >
> > Interfaces 1 and 3 are ATM interfaces. 2 is the MPLS core. 
> PE1 and PE2 
> > are responsible for Pseudo Wire Emulation.
> >
> > A Virtual Trunk extends from ATM Switch 1 to ATM Switch 2. 
> When the VT 
> > is provisioned, the PEs learn that all cells with a VPI in 
> the range 
> > {L, U} should be mapped onto a specific Pseudo Wire using n:1 cell 
> > mode encapsulation. The PEs don't have to know the state of 
> individual 
> > VCs. They are not involved in the setup of VPCs and VCCs. The only 
> > thing they do is mapping VPIs to Pseudo Wires Labels.
> >
> > The two ATM Switches behave as if the Virtual Trunk is a regular 
> > interface between them. There is one routing channel to exchange 
> > topology information and one signaling for connection setup. ATM 
> > routing and signaling information is transparent to the LERs.
> >
> > OAM for Virtual Trunks is still being debated in the MFA. I would 
> > rather wait with describing the full solution until we have 
> agreement 
> > within the MFA. However, I can respond to your question "Why do we 
> > have to transmit status of individual VPs in the LDP control 
> > protocol?" The answer is, we don't. The primary goal of 
> Virtual Trunks 
> > is to define a solution in which the PEs are not aware of 
> the status 
> > of individual VPs. Whatever solution the MFA comes up with, it will 
> > not require the use of PW Status notification for individual VPs 
> > within a Virtual Trunk.
> >
> > Peter
> >
> > >
> > >
> > [snipped to the end]
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>