Subject: RE: draft-stokes-vkompella-ppvpn-hvpls-oam-02.txt

From: [email-masked]
Date: Tue, 11 Nov 2003 11:07:11 -0000

Ali Sajassi wrote 11 November 2003 06:46
> 
> At 11:26 AM 11/10/2003 +0000, [email-masked] wrote:
> >Ali....I agree with what you say here.  But have you noticed 
> that you are 
> >effectively contradicting your recent posting to the PWE3 
> list wrt (in 
> >your view) not retaining the FCS in ethernet?  That is, the 
> ethernet FCS 
> >*belongs* to the ethernet client and must be independent of 
> whatever the 
> >server layer is....which is as you correctly note below, ie 
> we must have 
> >layer (in this case OAM) independence.  The fact that one 
> may have to do a 
> >linear update of the FCS on a link-connection basis does not 
> alter this 
> >fact.  Indeed, from a G.805/809 functional arch perspective, 
> the ethernet 
> >FCS belongs to the client->server adaptation process and 
> obviously applies 
> >on all client layer ethernet link-connections (as provided 
> by server layer 
> >trails).
> 
> In case of EVPL, do you consider service multiplexing field 
> as part of the 
> client data ? VLAN filed of the EVPL service is analogous to 
> DLCI field of 
> FR service.
> 
> Yours,
> Ali
Ali, What do you mean by a 'service muxing field'....the VLAN ID?  The key issue here is that some of the client O/H belongs to the trail termination function and some belongs to the client/server adaptation function.  If there is a FCS present and it covers the link-connection ID field then this belongs to the client/server adpatation function, and so must have a linear update for each client/server link-connection ID change.  If there is a FCS present and it does not cover the link-connection ID then IMO it should belong to the trail term function (and is obviously not updated on each link connection change).

However, if you want a definitive answer to this I would ask someone like Maarten Vissers....and I'll check internally with my func experts.

regards, Neil
<snipped to end>